VoiceXML Review - Columns

Volume 3, Issue 2 - March/April 2003

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:

https://voicexmlreview.org/Aug2002/columns/Aug2002_first_words.html
https://voicexmlreview.org/Oct2002/columns/Oct2002_first_words.html

and in last month’s issue as well:

https://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 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.

1
1 A document level error has occurred. Goodbye.
1
1

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 ) 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

We’ve had a quick look at some of things to watch out for in the handling of events with common prefixes. Next issue, we’ll look at some new and interesting things related to VoiceXML.

Thanks to Matt Oshry (your faithful Speak and Listen columnist) for suggesting the topic for this issue’s column.

back to the top