A Sample Chapter from
Early Adopter VoiceXML
Book Title: Early Adopter VoiceXML Published by: Wrox Publication Chapter Number:   7 Chapter Title: VoiceXML with XSLT (HTML and WML) Author: Wrox Author Team Price $: 24.49 ISBN: 1861005628 Buy It Now: Click here Additional Info: Wrox Publication Copyright © Wrox Publication	VoiceXML

This chapter examines the use of the Extensible Stylesheet Language for Transformations (XSLT) as a tool for the generation of VoiceXML. I intend to illustrate a complete, end-to-end example of implementing a voice interface for a client-server database via XML and XSL. The case study will demonstrate the power of XSL for simultaneously delivering multiple interfaces to the same data by developing HTML and WML front-ends also.

Our case study takes us inside the rarified atmosphere of a fictional cash-strapped dot-com called MyRubberBands.com, purporting to be the "premier rubber bands site on the Internet". In the aftermath of the stock market meltdown, where our heroes saw their market valuation drop by over 95%, senior management, led by CEO Dr. Todd,  has decreed that adding WML and voice functionality to the existing order status web site is do-or-die. MyRubberband's competitors have just rolled out their own WAP/voice access solution, and an all-out effort is necessary to catch up. Follow the programmers as they embark on their project to quickly roll out an equivalent capability.

Our development team have decided to implement an XSLT-based solution to the problem. XSLT is an XML-based language for transforming input structured according to one XML vocabulary to structured output in another XML vocabulary, or some general text form.

XSLT treats the document to be transformed as a set of nodes. An XSLT stylesheet defines a set of rules, or templates. When a template matches one of the nodes in the source document, the output structure given in the template is created in the transformed document. XSLT uses the W3C XPath specification language to query XML data. XPath is strongly analogous to SQL, and lets us specify complex rules to match nodes in a document.

For a lot of applications, and for getting off to a quick start when processing XML, it is just the ticket – especially when you consider that XSLT is a relatively new technology so that processors should still have plenty of performance improvements possible. Use of an XSLT processor avoids the startup overhead of using a full parser API from a compiled language, making it more suited to dynamic web applications.

An XML schema is used to represent an export of the legacy database instead of a Document Type Definition (DTD) because the schema standard is now complete, and increasing numbers of developers will be looking for the extra power schemas offer, especially as new development tools become available. An excellent primer on schemas is available from the W3C at http://www.w3.org/TR/xmlschema-0/.

Scripts to export the database to XML format have been written using the Perl language, and the Data Base Interface (DBI) library. The Perl script shown was developed on Windows using Active State Perl, but should run on any platform, be it Windows or Unix. Many commercial databases, such as SQLServer 2000, are capable of exporting directly to XML, and so this step could be avoided entirely.

However, some thought can still be given to the future. Rather than develop a quick and dirty "throwaway" voice interface, by putting in a little extra work now, the engineers can build a reusable infrastructure. By exporting their database to an XML format, they access the power of XSL to create VoiceXML and WML interfaces, and are able to transparently replace parts of the existing HTML site with dynamically created pages.

• There will be a main menu of options. This is the entry point to the application, and the user can always return to it with a single voice command.

• Online help will always be available. This will use the VoiceXML <help> tag to simplify implementation, and also to overload any built-in help that may be offered by the voice platform.

• The number of available options from the main menu should be kept to a minimum. The total number of states should also be minimized. This means that the behavior of the current command should not depend on what the previous command issued was. For example, the word "menu" should always refer to the main menu in every context.

• The top-level commands from the main menu should always be active. If the main menu offers the command "foo", the user should be able to say "foo" at any point in later dialogs with the same result.

The following state diagram illustrates these design goals. The main options are "order status", "product list" (with a link to voice ordering via the existing phone service bureau), and "more information" to access a frequently asked questions list. For a more detailed examination of the issues to consider when designing voice applications, refer to Chapter 6. The order status menu leads to a variable number of additional choices, depending on the number of records in the user's order history.

Since most of the tables in the database are relevant to the requirements of the various interfaces, the developers plump for a "verbose" approach to their XML. They will dump all of the data from all of the tables into XML form, even though some of it may be unnecessary in the VoiceXML, WML, or HTML contexts.

The thing we are most interested is a customer record, because that will be the set of data needed to generate the voice interface for querying order status. Since we might have more than one customer in a file, each individual <customer> and their associated order history will be contained by a <customer_record> element. Note that the time stamps are in XSL's standard format, and won't translate easily for rendering by a TTS engine. The <customer_record> element that starts here is very lengthy, and is not closed until the associated addresses and order history that follows have been given.

As shown in the database schema, a customer can have one or more addresses. The XML representation should preserve the foreign key relationship with the customer table, and this relationship should not be dependent on the position of the elements. In this case, for example, both the customer profile and all associated addresses are nested within the <customer_record> tag. This is why all of the <customer_address> elements carry the customer_id attribute inside: it mirrors the relationship between the customer and customer_address tables in the database schema.

In this case, the database schema allows the customer_address table to store real physical addresses like billing and shipping addresses, or e-mail address for alternate methods of customer contact. Hence, the <customer_address> element can contain the optional <email> element.

Since the main objective of the voice application is to allow the user access to their order history and status information, it makes sense to include the history inside the <customer_record> scope. In this case, because we will need to enunciate the order time, and because we'd rather not use XSL's limited text processing capabilities, we'll add the attribute sayas to the <order_date> element. This provides a pronunciation that can be used with the VoiceXML <sayas> tag for TTS. However, the desired pronunciation of the date and time cannot be derived from the database alone, as addressed in the section Generating MyRubberbandsML.

Finally, to provide the user with detailed order information, the full product name and description must be available. This will also allow the user to ask for a product list, and eventually we can perhaps extend the interface to enable products to be ordered by voice. Note that the <product_list> is not associated with any particular <customer_record>.

Also note that, ideally, the <product_list> wouldn't actually be in the same document as the customer data. However, we'll keep everything in one file here to avoid the issue of linking between documents. It might amuse us to picture the harried developers reaching the same conclusion to save time and give themselves some chance of meeting their beloved boss's deadline. Later on, they will no doubt want to refine the process and generate smaller XML documents that can be processed more quickly.

This example is formatted to fit the space above, and for readability, adds quite a bit of whitespace between <product></product> tags that would probably not occur in a real document.