One thing weve learned from Web-based application development is that tools are useful only if they can reuse components and third-party libraries and make it easy to assemble applications. This article reviews how we can build modular speech applications using VoiceXML. The focus will be on the language constructs that VoiceXML provides for modularization and reusability and on vendor-specific approaches toward creation of a library of reusable dialogs for speech applications.

As a language, VoiceXML is designed for reusability and modularity. Similar to the Web paradigm, VoiceXML supports modularization of the application components through document-to-document navigation (through menus, form submits, subdialogs etc.). The "src" attribute associated with a number of VoiceXML elements allows URL-based loosely coupled integration.

Since we're used to a hyperlinked world today, we take this for granted, but if we compare it with speech applications developed earlier, it's really like comparing a huge compiled application with a loosely coupled yet integrated application. We're used to separating Web application functionality into multiple sets of scripts (Perl scripts, PHP pages, ASP.NET pages, JavaServer Pages), images, and other media. This capability has been leveraged by VoiceXML as the language supports division of applications into VoiceXML documents (which can be dynamically generated through server-side programming), grammars, prompts, and subdialogs.

However, we'd be kidding ourselves if we didn't acknowledge that development of rich, high-quality speech applications is complex. VoiceXML does make it really simple to assemble a speech application, but we still need to create complex grammars and dialogs that can handle the complex conversations that the application needs to support.

This is where we can utilize the skills available within the speech recognition industry in the form of dialog and grammar experts. And this is where reusable components come to the rescue. Reusable components represent best practices and frequently used dialogs/ grammars that can be used by an application developer (or, rather, an assembler) to create a high-quality speech application.

For instance, if we were to develop a stock-trading application, we'd need the ability to recognize the various companies traded on the stock exchange. If application developers were to include this capability as part of their own applications, they wouldn't be able to focus on the end application and would be lost in the functionality of recognizing all the possible companies. On the other hand, if a third party has already built such a dialog/grammar, it can be readily used, allowing developers to focus on the valued-added business scenarios rather than dealing with the complexity of recognizing all the companies.

Reusability Requirements
As speech application developers, what we need is a set of reusable dialogs and grammars that we can incorporate in our applications. We need grammars to recognize city names, streets, companies, businesses airlines, and airports as well as dialogs that use these complex grammars to recognize addresses, driving directions, credit card information, and the like.

In a nutshell, we need a set of published, reusable voice components. Apart from the components themselves, we need a methodology for creating and utilizing reusable components. Also required is the integration of reusable components with development tools and VoiceXML gateways and/or hosting providers so that applications built on top of the components can be readily built/assembled and deployed.

VoiceXML Subdialogs
Probably the most adopted approach for creating reusable dialogs is through VoiceXML's element. From a definition perspective a subdialog element invokes a called dialog identified by the src element in the calling dialog. The subdialog is then created and executed in its own temporary execution context and proceeds with execution until it encounters a element, at which point any information is returned to the calling dialog. Subdialogs can be parameterized through the param elements and are fundamental in building a set of reusable components for use within VoiceXML applications.

The following code snippet defines a subdialog that collects users' phone numbers and PINs and returns the information to the calling environment:

What is your phone
number?


...

...

The subdialog can then be used by another application to authenticate a user, as shown by the following snippet:

"GetUserInfo.vxml">

"GetUserInfo.phone">
...

VoiceXML subdialogs behave somewhat differently from traditional programming languages. Subdialogs execute in a "temporary" execution context. They can take parameters, but don't follow the event percolation model (events must be handled within the subdialog itself or be explicitly returned). Unlike external objects, subdialogs do limit what can be built as a component as they themselves also have to be VoiceXML code. However, subdialogs are also the only portable mechanism today to create reusable dialog components for VoiceXML applications. As we'll see later, subdialogs are the basis for the majority of vendor-specific reusable components as well.

VoiceXML