AW: Enhanced Event Handling

Thanks for responding; see my comments below.

-----Ursprüngliche Nachricht-----
Von: Kesava Neeli [mailto:kneeli@bevocal.com]
Gesendet: Mittwoch, 11. August 2004 18:26
An: Tobias Göbel; www-voice@w3.org
Betreff: RE: Enhanced Event Handling



Hi all, 

I'd like to add two points to the discussion of VXML 2.1. 

1) Changing properties in Event Handling 

>From a VUI perspective, it might be desirable to change the behaviour of the system slightly after the occurrence of certain events (NoInput, NoMatch etc.). E.g., the confidencelevel could initially be set to something like 0.6, and after one or two NoMatches in a row, the level could be decreased. Similar changes could affect parameters like "sensitivity", "timeout", "bargeintype" etc.

I currently don't see a way to achieve this consistently within VoiceXML. The <prompt> element allows setting bargein, bargeintype and timeout only, via attributes. This does not give you the full range of possible properties, though. (On the other hand, it only makes sense for a few properties to be changed after events - that might be bargeintype, timeout, confidencelevel, sensitivity and the like)

The idea was to allow the <property> element to appear as a child of <catch> or similar elements, so that e.g. after the second NoMatch, the confidencelevel could be changed as follows:

<catch event="nomatch" count="2"> 
  <property name="confidencelevel" value="0.4"/> 
  <prompt>Please try again. I will sharpen my ears...</prompt> 
  <reprompt/> 
</catch> 

Defining a property at this level would affect the scope of the <catch> element itself (e.g. a <field> or a <form>). 
The only way to do this using the current VXML spec would be to <goto> or <submit> to a new dialog/document inside the <catch> element I guess.

An alternative would be to add new attributes to <prompt>, like "confidencelevel", "sensitivity" and so on. 
[Kesava Neeli] This is a good point and our internal applications team had the same problem. I am not sure whether it will be okay to have the <property> as a child element since it's active to that catch scope only and a recognition state like <field> is in a different scope. We added a extension to our browser where we could set the property using a "expr" attribute. This still doesn't solve this problem you mentioned completely but helps us little bit.
  
[Tobias Göbel] Yes, when having the <property> as a child of <catch>, the scope would have to be enhanced to that of the <catch>'s parent. Where exactly can you specify your proprietary "expr" attribute? 

2) Different grammars at different error levels 

This goes in the same direction as my first point. A VUI designer might define simple NoMatch or NoInput prompts followed by some kind of reprompting. If some different behaviour is desired after certain events (like after two NoMatches: "I still didn't get you. Let's try this differently. Please only give me the name of the city first" ...), a jump to a new dialog/document would usually be performed.

If it were possible to activate different grammars at different event levels, this would allow to stay in the same form item (given that the variables to be filled wouldn't change). 

Another use case would be that typically user utterances change slightly after having heard a simple NoInput/NoMatch prompt (like in "Sorry, I didn't get you. What did you say?" - "I said..." or "what I said was ....."). You would have to add these ("garbage") phrases to the same grammar that is already active for the initial prompt. Having different grammars for different states as described would solve this problem and facilitate a more adequate grammar engineering.

It could be achieved by allowing the definition of <grammar> elements within event handlers, overriding all (?) active dialog grammars except for those coming from <link>s.

[Kesava Neeli] This can be achieved using <grammar srcexpr=".."/> where the URI is evaluated dynamically. This is in 2.1 and many browsers have this as an extension already..
[Tobias Göbel] But will the grammar be reloaded anew (thus triggering a re-evaluation of the srcexpr) after returning from an event handler? I guess not, so we have the same problem. Only one grammar possible while staying in the same form item (or form)...


All comments on this are appreciated. 

Thanks and regards 

Tobias Göbel 
Partner Consultant 

VoiceObjects AG - simplifying voice technologies - 
   Friedrich-Ebert-Strasse 
   D 51429 Bergisch Gladbach 

   Fon:   +49 (0)2204 / 845-159 
   Fax:   +49 (0)2204 / 845-110 
   Email: tgoebel@VoiceObjects.com 
   Web:   www.VoiceObjects.com 

SpeechTEK will celebrate its 10th Anniversary  
Join us at SpeechTEK 2004 booth # 800, 
September 13 -16, 2004 at the Hotel New York Marriott Marquis.