VoiceXML Events

By Rob Marchand

Welcome to "First Words" - the VoiceXML Review's column to teach you about VoiceXML and how you can use it. We hope you enjoy the lesson.

Event Propagation

Overview

Last issue, we looked at a few examples of event handling, to ensure that we understand how event handling works. A good foundation in this area will allow you to build a more resilient application, and be sure that the caller experience remains consistent. We’re all off to SpeechTek, so this is a short column. Hope to see you at the VoiceXML User Group Meeting!

Just as a reminder, we have talked about events in some detail in two previous columns:

http://www.voicexmlreview.org/Aug2002/columns/Aug2002_first_words.html
http://www.voicexmlreview.org/Oct2002/columns/Oct2002_first_words.html

and in last month’s issue as well:

http://www.voicexmlreview.org/Mar2003/columns/Mar2003_first_words.html

It might be a good idea to take a look at these previous columns, if you haven’t already.

This time around, we’re going to have a look at a very specific area of interest – how catch handlers are selected. The reason we’re going to focus on this is that it can be a source of some confusion.

Here is the description of the <catch> handler selection algorithm from the current VoiceXML specification:

1. Form an ordered list of catches consisting of all catches in the current scope and all enclosing scopes (form item, form, document, application root document, interpreter context), ordered first by scope (starting with the current scope), and then within each scope by document order.
2. Remove from this list all catches whose event name does not match the event being thrown or whose cond evaluates to false after conversion to boolean.
3. Find the "correct count": the highest count among the catch elements still on the list less than or equal to the current count value.
4. Select the first element in the list with the "correct count".


This algorithm has been taken verbatim from the currently published Candidate Recommendation for VoiceXML 2.0, located at:

http://www.w3.org/TR/2003/CR-voicexml20-20030128/

Where this becomes interesting is when the document author makes use of VoiceXML’s prefix-matching capability in conjunction with event counters. The reader may recall that it is possible to specify a catch handler that exactly matches a particular event, or one that matches a set of events. This is based upon a prefix match. From the specification:

The name of a thrown event matches the catch element event name if it is an exact match, a prefix match or the catch event name is not specified. A prefix match occurs when the catch element event attribute is a token prefix of the name of the event being thrown, where the dot is the token separator, all trailing dots are removed, and the empty string matches everything.

What this means is that you can specify a catch handler with an event attribute like ‘error.badfetch’, and it will be considered for catching events including error.badfetch, error.badfetch.http, error.badfetch.http.404, and so on.

This seems clear enough. However, when combined with event counters, the selection of an event can appear complex.

Here is a stripped down version of the example from last month.

<?xml version = "1.0"?> <vxml version = "2.0"> 1 <catch event = "error.badfetch” count=”2"> 1 A document level error has occurred. Goodbye. 1 <exit /> 1 </catch> <form> 2 <catch event = "error.badfetch”> 2 A form level error has occurred. 2 <clear namelist=”orderCount” /> 2 </catch> <field name = "orderCount"> <grammar type = "application/srgs+xml" src = "digits.grxml" /> <prompt> How many <value expr = "orderItem" /> would you like? </prompt> </field> <filled> <prompt> One moment while I add <value expr = "orderCount" /> items to your order. </prompt> <submit namelist = " orderCount" next = "pizzaCart.php" /> </filled> </form> </vxml>

The key thing is to remember this – when an event occurs, it increments the counters for all prefix events as well. So an error.badfetch.http.404 event within the dialog above (while performing the <submit/>) will increment the event counters for error.badfetch.http, error.badfetch, and error as well.

Now, if within the same dialog we then have a second different event such as error.badfetch.http.503, handlers may not be invoked the way you expect. It is important to remember that this will be the first occurrence of error.badfetch.http.503, but the second of error.badfetch.http, error.badfetch, and error. This means that a catch handler for, say, error.badfetch, with an event counter of ‘2’ would not be invoked when the second event is thrown. This is because this is the first occurrence of error.badfetch.http.503, and the error.badfetch will be removed from the list of handlers under consideration. So the document level event handler will not be invoked as you might expect, given it’s event count attribute.

Watch for some clarification of this behavior in the next release of the VoiceXML 2.0 specification.

Summary

back to the top

 

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