Sample Chapter: Early Adopter VoiceXML - Generating MyRubberbandsML

(Page 5 of 9 )

Now we have examined the existing database, outlined a suitable voice interface for it, and defined our source markup language and the method for generating it. Now, we are ready to create a stylesheet to convert it to a VoiceXML form implementing the design we decided on in the previous section Designing A Voice Interface. This stylesheet, myrubberbands2vxml.xsl, is quite lengthy, and can be found in its entirety in the code download. Here, I shall pick out just the important points in the code for discussion; including the dynamic generation of grammars, some VoiceXML features worthy of particular attention, and fundamental XSL concepts used.

VoiceXML Stylesheet
Note that the stylesheet is designed to produce a single VoiceXML document containing just one user's data. So, its top-level template only matches documents where the top-level attribute export_type is set to single. The indent attribute on the <xsl:output> tag will produce a well-formatted result document that will be easier for a human brain to examine.

<?xml version = "1.0"?>
<xsl:stylesheetxmlns:xsl="http://www.w3.org/1999/XSL/Transform"
version="1.0">

<xsl:output method="xml" encoding="ISO-8859-1"
indent="yes"/>

<xsl:template
match="myrubberbands[@export_type='single']/customer_record">
<vxml version="1.0">

<meta name="author" content="Underpaid Myrubberbands
Engineer"/>
<meta name="copyright" content="Copyright (C) 2001
Myrubberbands.com"/>

The next block illustrates one way XSL can generate elements with an attribute having dynamic content: the <xsl:element> construct.

<xsl:element
name="meta">
<xsl:attribute
name="name">description</xsl:attribute>
<xsl:attribute name="content">Voice
Interface for #<xsl:value-of select="customer/@id"/>
</xsl:attribute>
</xsl:element>

We will need to set up some variables for use in the VoiceXML document. First off, we grab the user's Automatic Number Identification (ANI) and Dialed Number Identification Service (DNIS) for later use. These correspond to the phone number that originated the call (analogous, but not identical to, the consumer caller ID service) and the number that the user dialed. The implementation of these is system dependent, and the data may not be available for all calls in any case. They are included here mainly for illustration. In a real application, the ANI can be used for auto-identification of the user.

The form_pointer variable will be used for navigation later.

<var name="customer_ani"
expr="session.telephone.ani"/>
<var name="customer_dnis"
expr="session.telephone.dnis"/>
<var name="session_error_count" expr="0"/>
<var name="form_pointer" expr="'mainMenu'"/>
<var name="user_command" expr="''"/>

Next come the form level help dialogs, which here attempt to mimic typical responses likely from a real life call center, contrary to the advice of Chapter 6:

<help count="1">
What seems to be the trouble?
<reprompt/>
</help>
<help count="2">
Come on - isn't this easy enough to understand?
<reprompt/>
</help>
<help count="3">
Hey <xsl:value-of
select="customer/firstname"/>, are you stupid or something?
<reprompt/>
</help>

The design specifies that the main menu command is always available. We can implement that with a global VoiceXML <link> element:

<link next="#mainMenu">
<grammar type="application/x-jsgf"> main
menu </grammar>
</link>

Again, we use the information from the XML file to customize the prompts for the user. This form welcomeMessage corresponds to the "welcome message" box in the interface design diagram earlier.

<form
id="welcomeMessage">
<block>
<prompt bargein="false"
timeout="0.1s">
Hello, <xsl:value-of
select="customer/firstname"/>.
Welcome to the my rubber bands dot com
voice order status system.
</prompt>
<goto next="#mainMenu"/>
</block>
</form>

Next, we come to the mainMenu form, the primary form of the voice application. There is a form level <nomatch> element here to transfer control flow to the errorHandler form when an utterance doesn't match the grammar. This form is used for most no-match events throughout the application, to keep track of the total number of such errors that have occurred this session. The <noinput> handler here ensures the main menu is repeated when the user doesn't respond to the prompt. In a future version of the product, the designers may implement some kind of timeout to restrict the number of loops, and disconnect the user if there is no response for a long time, but this issue need not concern us now.

Next: Generating MyRubberbandsML (contd.) >>
 

More XML Articles
More By Tim Pabst

Comments On: Sample Chapter: Early Adopter VoiceXML

>>> Be the FIRST to comment on this article!