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.

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


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. 

Received on Wednesday, 11 August 2004 16:27:58 UTC