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 talked about how events are propagated within the VoiceXML environment. This issue, we’re going to look at a few examples, to ensure that we understand how this works. This will allow you to build a more resilient application, and be sure that the caller experience remains consistent.

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.

An Example

Here is an example, which we’ll use to describe various event-handling scenarios.

We’ve added a few <catch> handlers to our VoiceXML pizza page (remember that <noinput> is the same as <catch event=”noinput”> ). We’ve also flagged each of the event handlers in sequence (see the numbers in the left-had column). Here is what will happen when various events are thrown:

• If an error is generated while trying to fetch this page, the event handling will happen in the context of the document that is trying to transition to this one;
• If a <noinput> event is generated while in the first field (orderItem), event handler ‘4’ will be triggered – this is within the anonymous scope of the <field>.
• If a <nomatch> event is generated while in the first field (orderItem), event handler ‘5’ will be triggered - this is within the anonymous scope of the <field>.
• If a <noinput> event is generated while in the second field (orderCount), event handler ‘3’ will be triggered – this will be done as a copy of this event handler was within the <field> element itself.
• If a <nomatch> event is generated while in the second field (orderCount), event handler ‘6’ will be triggered – again, this is within the field scope.
• If an error occurs during the evaluation of the ECMAScript expressions ‘orderCount’ or ‘orderItem’, an error.semantic event will be thrown. As there is no specific event handler for this, the general error handler at the document level (event handler ‘1’) will be triggered – again, as if it were copied into the scope where the ECMAScript evaluation occurred.
• If an error occurs during the attempt to transition to the next document (using the <submit> tag), then the result will depend upon the error. We have a specific event handler a the <form> level for a particular kind of HTTP failure. If this is the failure that occurs, then the event will match, and the form level handler (event handler ‘2’) will be invoked. Any other error.badfetch.http event (or error.badfetch, or error, for that matter) will be caught at the document level by event handler ‘1’.

For the sake of this example, we’ve done a few things that are not good practice:

• <noinput> and <nomatch> are often best place in the <field> and handled specifically for the field;
• We just disconnect for any error – there may be recovery actions that can be taken;
• We don’t handle all errors;
• It would be useful to log the particular event and message in general event handlers;
• Our error messages are not terribly informative.

Things to Watch Out For

Once again, here is our list of things to keep in mind:

1. Make sure you understand the catch element description algorithm, in particular how names are selected, and how event counts work, if you are using them. – This will avoid surprises in your application error handling;
2. Remember – Semantic errors in a page that is being fetched will be thrown in the context of the document doing the fetching. So if a target page has a ‘compile-time’ error that can be detected, it will show up the page that is trying to fetch it. These errors include HTTP fetch errors, poorly formed XML documents, and so on.
3. Events thrown in a subdialog won’t be passed to the calling document unless you explicitly ‘return’ an event in the subdialog <return> tag using the ‘event’ attribute. This is often a surprise to new developers.
4. Errors that occur after entering the Form Initialization Algorithm (FIA) initialization phase (i.e. the target document is executing), such as semantic errors, are raised in the new document, and will be handled by event handlers as selected in that scope;
5. Errors that occur after loading and before entering the initialization phase of FIA are handled in a platform-specific manner;
6. The handling of errors encountered during the loading of the first document in a session is platform-specific.

For the last two, you should consult your platform provider to determine the behavior of event propagation in these circumstances.

Summary

This time around, we’ve looked at how events are propagated in VoiceXML applications. Next column, we’ll explore event propagation further. Hope you’re enjoying the summer! (And don’t forget to sign up for the VoiceXML User Group meeting happening at the fall SpeechTek).

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