VoiceXML Review - Columns

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.

Now that you've been inundated with information about VoiceXML 2.0, we're going to have a look at subdialogs, and how they can be used to structure your application.

Subdialogs act as a subroutine call to a VoiceXML dialog. This dialog can collect information from the user, validate, reprompt, and handle errors. Once complete, the subdialog can return either an ECMAScript object (with properties specified by the subdialog) or an event, which is then thrown in the context of the subdialog call.

One of the most interesting uses of subdialogs is to completely encapsulate a reusable piece of dialog. One could easily imagine, for example, providing a generic confirmation dialog, or a subdialog responsible for collecting a 'yes/no' response from the user. In fact there are many such components available today. Historically, these have been implemented (by necessity) as part of a speech vendor's proprietary solution. However, VoiceXML brings the ability to share these dialog components across multiple VoiceXML platforms, and to mix and match them. Suppliers of these dialogs can now provide their dialog tools as a collection of server-side components written in a standard dynamic page generation language (for example, Java combined with Java Server Pages), along with the supporting grammars and prompts. These can then be used in your application quite easily.

Now that we've convinced ourselves they're useful, let's have a closer look at subdialogs.

Subdialogs are classed as form items, similar to <field>, <block>, <record>, <transfer> <object>, and <initial>. Form items are elements visited during the processing of the Form Interpretation Algorithm (FIA). The field items in this list (field, record, transfer, object and subdialog) collect data to fill a field item variable. So, subdialogs can be thought of in the way as we think of a <field> element. It will therefore typically replace the VoiceXML code for a field within a form.

As we mentioned above, the subdialog itself acts as a subroutine call with named parameters. When the subdialog is processed, the existing page state, grammars, and variables are saved, and the subdialog executes in a new VoiceXML 'context'. This context includes the current 'global' state (application level variables and the like), but the subdialog can't modify these in the caller's scope. That is, any changes we make will be visible only within the subdialog.

Subdialog also accepts the usual collection of fetch attributes (fetchaudio, etc.), and cache control attributes (caching, etc. for VoiceXML 1.0, maxage and maxstale for VoiceXML 2.0). Subdialog in VoiceXML 1.0 included a modal attribute, which restricted the grammars that were available within the subdialog to those that were defined in the subdialog. This attribute has been removed in VoiceXML 2.0, and normal grammar scoping applies.

The subdialog field item can contain all the usual form item components, such as <prompt>, <filled>, and so on. It may also have <param> elements, which define the parameters that are to be passed to the subdialog. These parameters must have a corresponding variable declaration within the subdialog, using the <var> tag.

The passed parameters are assigned to the variables in document order in the subdialog variables. The name attribute of the subdialog call, and the name attribute for the corresponding variable must match. If you have have an expr attribute on these variables, it will be ignored unless no corresponding param is passed, in which case the expr will be used as a default.

As usual, we'll fall back on our traditional pizza franchise to demonstrate how we might make use of subdialogs in an application.

We've decided that plain pizzas are pretty boring. We therefore want to be able to collect a list of pizza toppings. This could involve an involved conversation with the user, so we're wrapping this up in a subdialog in order to break it out from the main conversation with the caller.

In the sample below, we have a form that can collect a list of toppings. We basically prompt the user to select from a list of toppings, and to say 'done' when they are finished.

<form id="getToppings">
    
    <!-- Arguments -->
    <!-- We don't actually use item here, but we could confirm that we are
          ordering a pizza, for example, or select toppings based on the item. -->
    
    <var name="item"/>

    <!-- Local -->
    <var name="topping_list" expr="' '"/>

    <field name="topping"
            <grammar>
                green peppers | cheese | pepperoni | ham | pineapple | done
            </grammar>

            <prompt>
                You can choose from: green peppers, cheese, pepperoni, ham,
                pineapple, or say done
            </prompt>

            <filled>
                <if cond="topping != 'done' ">
                    Okay. Added <value expr="topping" />
                    <assign name="topping_list" expr="topping_list + ' ' + topping"/>
                </if>
            </filled>
    </field>

    <filled>
           Thanks.
            <return namelist="topping_list"/>
    </filled>

</form>
</vxml>

This is clearly a simple example. We aren't doing anything with the argument being passed in, for example, but we do perform some dialog with the user, and assemble a result to be returned to the calling application.

Subdialogs

By Rob Marchand