vxi-discuss



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Question about Event Handing in VXML



I believe that the current VoiceXML 2.0 working draft clarifies this:
 
-- begin quote (section 5.2.4) --

When an event is thrown, the scope in which the event is handled and its enclosing scopes are examined to find the best qualified catch element, according to the following algorithm:

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

The name of a thrown event matches the catch element event name if it is either an exact match or a prefix match. A prefix match occurs when the catch element event attribute is a prefix of the name of the event being thrown. For example,

<catch event="telephone.disconnect"> 

will prefix match the event telephone.disconnect.transfer.

Note that the catch element selection algorithm gives priority to catch elements that occur earlier in a document over those that occur later, but does not give priority to catch elements that are more specific over those that are less specific. Therefore is generally advisable to specify catch elements in order from more specific to less specific. For example, it would be advisable to specify catch elements for "error.foo" and "error" in that order, as follows:

<catch event="error.foo"> 
  ...
</catch> 
<catch event="error"> 
  ... 
</catch> 

If the catch elements were specified in the opposite order, the catch element for "error.foo" would never be executed.

-- end  quote --
 
This means that, for your case 2 scenarios, the following happens:
 
1. <throw event="error.x"/>
2. <throw event="error.y"/>
3. <throw event="error.y"/>
A. <catch event="error"> <!-- catch event 1 here -->
B. <catch event="error" count="3"> <!-- catch event 3 here -->
C. <catch event="error.y" count="2"> <!-- catch event 2 here -->

and in your last example
 
5. <throw event="foo.bar">
J. <catch event="foo"> <!-- catch event 5 here -->
K. <catch event="foo.bar">

 
Hope this helps... and that my reading of the spec is correct :-)
 
Marius Milner
Avaya Inc.
mariusm@avaya.com
-----Original Message-----
From: Brian Eberman [mailto:brian.eberman@speechworks.com]
Sent: Thursday, March 15, 2001 10:49 AM
To: Vxi-Discuss
Subject: Question about Event Handing in VXML

We are updating the event handling implementation in the VXI and actually have a question about the event model. Your comments would be appreciated.

------

[ VoiceXML 1.0 -  Chapter 11]

Events may occur as the result of document processing or recognition and my be explicitly thrown by the application. Both are functional equivalent to a statement of form

<throw event="event_name"/>

The event names must satisfy the rules of NMTOKEN (i.e. be composed of letters, digits, ':', '_', '-', and '.').  The OpenVXI will use '.' to determine prefix boundaries within events. This is important for the prefix matching rules in section 11.4. The prefix matching rules result in an inheritance among events. For instance,

<throw event="error.x"/>

may be caught by either

<catch event="error"/>
<error>

but not by

<catch event="err"/>
<catch event="error./">

as might be allowed by a liberal interpretation of the match criteria. When events are thrown, counts will be incremented for each event and prefix (i.e. foo.bar.ack will increment 'foo', 'foo.bar', and 'foo.bar.ack').

I'd like to examine two difficult cases and see how these play out. In each case, three events will be thrown and several handlers will be competing to catch each.


Case 1:
-------

This case uses the prefix and explicitly shows the event counts at each step.

1. <throw event="error.x"/>
2. <throw event="error.y"/>
3. <throw event="error.z"/>

A. <catch event="error">
B. <catch event="error.y" count="2">
C. <catch event="error" count="3">

The first event will be handled by A. There has only been one error and only A matches it.
--> The counts are (error=1, error.x=1)

The second event will be handled by A. There have not been three events and only one 'error.y' has occurred.
--> The counts are (error=2, error.x=1, error.y=1)

The third event will be handled by C. Even though this is the first error.z event, it is the third 'error' event.
--> The counts are (error=3, error.x=1, error.y=1, error.z=1)


Case 2:
-------

Notice that the third event is now an 'error.y' and that the event handlers have been reordered. The first two events follow case #1.

1. <throw event="error.x"/>
2. <throw event="error.y"/>
3. <throw event="error.y"/>

A. <catch event="error">
B. <catch event="error" count="3">
C. <catch event="error.y" count="2">


The first event will be handled by A. There has only been one error and only A matches it.
--> The counts are (error=1, error.x=1)

The second event will be handled by A. There have not been three events and only one 'error.y' has occurred.
--> The counts are (error=2, error.x=1, error.y=1)

The third event is more tricky. Both B and C are possible. This is the third error and the second 'error.y'. The criteria specified in section 11.4 requires that the interpreter "select the first element in the list with the 'correct count'". This makes sense for cases where duplicates occur. So

5. <throw event="foo">
J. <catch event="foo">
K. <catch event="foo">

event 5 would always be handled by J. However if

5. <throw event="foo.bar">
J. <catch event="foo">
K. <catch event="foo.bar">

would event 5 still be handled by J?

This is certainly true of C++ where the equivalent code looks something like this:

class foo;
class foo_bar : public foo;

try {
throw foo_bar();
}
catch (const foo &) {
// Code here will be run.
}
catch (const foo_bar &) {
// This will never be used.
}

This model, however, may not be valid. Certainly the inheritance of event handlers 'as if by copy' in VXML is quite different from C++. Likewise, this interpretation violates the goal of finding the 'best qualified catch element' as K is certainly more qualified than J.

We propose changing the selection criteria in 11.4 so that rule 4 reads: "Select the element in the list with the 'correct count' which best matches the name of the event. If two catches have the same name, the first element in the list will be chosen."

____________________________________________________________________
 Brian Eberman

Director of Engineering                         Open Speech and System Products
SpeechWorks International                  
http://www.speechworks.com
695 Atlantic Ave
Boston, MA 02111
(617) 428 4444

 



This page is maintained by Alan W Black (awb@cs.cmu.edu)
speechinfo.org is hosted on a machine donated by VA Linux Systems
VA Linux Systems