Home arrow XML arrow Page 3 - Sample Chapter: Early Adopter VoiceXML

Sample Chapter: Early Adopter VoiceXML

Ever wondered what VoiceXML is? In this sample chapter from Wrox we will learn a bit more about it and see a working example of VoiceXML in action.

Author Info:
By: Tim Pabst
Rating: 5 stars5 stars5 stars5 stars5 stars / 3
September 04, 2002
  1. · Sample Chapter: Early Adopter VoiceXML
  2. · VoiceXML With XSLT (HTML and WML)
  3. · System Architecture
  4. · System Architecture (contd.)
  5. · Generating MyRubberbandsML
  6. · Generating MyRubberbandsML (contd.)
  7. · Generating MyRubberbandsML (contd.)
  8. · Running the Stylesheet
  9. · Summary

print this article

Sample Chapter: Early Adopter VoiceXML - System Architecture
(Page 3 of 9 )

The figure below is a block diagram showing the existing components of the system, and the relationships to the new XML/XSLT system required to implement the voice interface.

The existing components of the system

This drawing is not complete in all areas. For example, no method for user login and authentication is given, because such a system would already exist for an e-commerce site, and because although XML/XSLT would be helpful for creating device-specific login code, we are not going to examine on-the-fly transformation (inside a web server, for example) in this particular study.

Designing a Voice Interface
With these rather vague requirements in mind, we can make some design decisions, and sketch out a rough model for the voice interactivity envisaged. The goal is to make the experience simple and intuitive.
  • 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.

The order status menu chart

Creating a Markup Language
Naturally, our fictional rubber band team already has a database-driven e-commerce web site. Like all legacy databases, it has evolved over time into a hodgepodge of tables, some of which were hastily knocked together to implement poorly-defined requirements. We will assume that the company is operating a traditional Java Server Pages (JSP) site.

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.

MyRubberbandsML by Trial and Error
The first thing any XML dialect needs is a top-level element. Since we might want to export all the customers in the database, or only one at a time, let's add an attribute on the top level element to describe what kind of data feed this XML document constitutes.

<myrubberbands export_type="single">

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.

<customer id="1">

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.
blog comments powered by Disqus

- Open XML Finally Supported by MS Office
- XML Features Added to Two Systems
- Using Regions with XSL Formatting Objects
- Using XSL Formatting Objects
- More Schematron Features
- Schematron Patterns and Validation
- Using Schematron
- Datatypes and More in RELAX NG
- Providing Options in RELAX NG
- An Introduction to RELAX NG
- Path, Predicates, and XQuery
- Using Predicates with XQuery
- Navigating Input Documents Using Paths
- XML Basics
- Introduction to XPath

Watch our Tech Videos 
Dev Articles Forums 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us 
Weekly Newsletter
Developer Updates  
Free Website Content 
Contact Us 
Site Map 
Privacy Policy 

Developer Shed Affiliates


© 2003-2019 by Developer Shed. All rights reserved. DS Cluster - Follow our Sitemap
Popular Web Development Topics
All Web Development Tutorials