ECMAScript

By Rob Marchand

Welcome to First Words, VoiceXML Review's column that teaches you about VoiceXML and how you can use it. We hope you enjoy the lesson.

Last month we looked at a few samples of what to do with our pizza application on the server-side. Hopefully that gave you some ideas about how VoiceXML fits into the web model of development. This month, we're going get started with ECMAScript.

Previously we've looked at a few different ways of processing the information we've collected from the user. Going to the server brings us the ability to take advantage of any software and hardware capabilities that might be hosted there, at the expense of a slight delay. However, VoiceXML includes a built-in scripting language intended for use on the VoiceXML gateway itself, much as web browsers have included JavaScript and Jscript (and no, we're not going to have that argument now) to allow the development of user interfaces that are more responsive and fully featured.

As with any tool, the benefit will depend upon how you use it. It doesn't make sense to use ECMAScript to re-invent the applications and capabilities that already exist on your servers. However, it does make sense to use it to do many of the lightweight tasks that come up in interface development. An additional benefit is that the processing is likely to be more understandable, as the code doing such tasks will be 'close' to the code it is working with.

The scripting support in VoiceXML gives you the capability to do things like input validation and filtering, calculations, and parsing and reformatting of data on the VoiceXML gateway. Although these could also be done on the server, the overhead of the transaction with the server may dominate the time spent in performing the function. In addition, the actual interaction with the application server itself may involve much more than a simple CGI execution, and might also include transaction handling, session management, and so on, even for such a simple request. So, for example, you could range-check the user's input within the VoiceXML page itself, rather than asking the server to do it for you.

This is all well and good, but what is ECMAScript anyway. ECMAScript is the European Computer Manufacturer's Association (ECMA) standard for a scripting language. It is currently in its third edition, and can browsed at: http://www.ecma.ch/ecma1/STAND/ECMA-262.HTM, or downloaded at: ftp://ftp.ecma.ch/ecma-st/Ecma-262.pdf. (Note that the link given in the VoiceXML specification, http://www.ecma.ch/stand/ECMA-262.htm, no longer works).

The original ECMAScript standard (Edition 1) was based on JavaScript 1.1. JavaScript 1.3 is the first JavaScript version that was compliant with the published ECMAScript standard (this may sound odd, but Edition 1 normalized and extended the language beyond JavaScript 1.1). JavaScript 1.4 is also compliant with Edition 1, and the forthcoming JavaScript 1.5 will be compatible with ECMAScript Edition 3 (Edition 2 was primarily corrections and clarifications, rather than feature set changes).

Most VoiceXML platforms will support JavaScript 1.3 or 1.4, or perhaps an early release of 1.5. You might find it useful to have a look at the documentation for these at: http://developer.netscape.com/docs/manuals/javascript.html.

The short story is that for all intents and purposes, ECMAScript and a relatively recent release of JavaScript are the same thing. One suggestion, though; find out what version your platform provider is using, and check out the documentation at the link above. You may want to stay away from JavaScript features that extend beyond the ECMAScript specification, for the sake of portability. The two will likely leapfrog each other from time to time (in terms of available capability).

ECMAScript and VoiceXML

How does ECMAScript fit into VoiceXML?

• VoiceXML variables are completely equivalent to ECMAScript variables;
• ECMAScript objects are used as the parameter passing mechanism for elements such as <subdialog> and <object>;
• The 'expr' attribute available with many tags defines an ECMAScript expression;
• ECMAScript can be placed in-line in the VoiceXML document using the <script> element; scripts can also be loaded from a URI;
• Variable scoping (mostly) follows the ECMAScript model (session -> application -> document -> dialog -> anonymous).

This leads to some nifty benefits. For example, you can access VoiceXML variables within JavaScript. Elements that accept the 'expr' attribute can use arbitrary ECMAScript code to generate a value at runtime. And you can abstract your commonly used ECMAScript functions into functions or libraries to support reuse in your VoiceXML pages.

Back to the Pizza

In our last column, we were trying to figure how much to charge the caller for their order. In reality, this is going to be done on the back-end with a shopping cart kind of application. In our sample, we were using some simple server-side scripts to calculate the cost of the order. We can just as easily (well, more easily) do this on the client side, and implement both application pieces on the client-side in a single VoiceXML page.

To do this, we make the following changes to the page (the entire new VoiceXML page is at the end of the article):

1) Propagate the data we've collected to the second form

Up until this point, we've been using variables that are scoped to a particular form (dialog scope) or block (anonymous scope). Once we've collected our information, we use it within the form, and we're done. In this case, we want to propagate it from form to form. To do this, we'll declare two document scope variables (for a good discussion of scope, and examples of how it impacts your development, see the VoiceXML Forum tutorial at http://www.voicexml.org/tutorials/tutorial3_1.html). We do this by adding these declarations before the first form:

<var name="orderItem"/>
<var name="orderCount"/>

and, within the filled block for the first form:

<assign name="document.orderItem" expr="orderItem"/>
<assign name="document.orderCount" expr="orderCount"/>

There are those who will say "Don't overload variable names like that!", and they're right. But I'm illustrating the technique of referring to variables in parent scopes using their scope designator ('document' in this case).

2) Transition to another form instead of submitting to a web server

This is done by adding a <goto> to the <filled> block for the first form:

<goto next="#makeMeRich"/>

which transitions to the URI named. This happens to be on the same page (and follows the same conventions as the URIs you've used before). Note that if no successor form is specified, the telephone call would disconnect at this point.

3) Create the form that will replace the server-side script

This form will calculate the cost of the order, and play the prompts in exactly the same manner as the form produced by the server-side page.

back to the top

Copyright © 2001 VoiceXML Forum. All rights reserved.
The VoiceXML Forum is a program of the
IEEE Industry Standards and Technology Organization (IEEE-ISTO).