W3C home > Mailing lists > Public > www-voice@w3.org > April to June 2002

VoiceXML comments from Elvira development team - part III

From: Pavel Cenek <Pavel.Cenek@itek.norut.no>
Date: Fri, 19 Apr 2002 09:44:14 +0200
Message-ID: <3CBFCACE.7080506@itek.norut.no>
To: www-voice@w3.org

    I am one of the developers of a VoiceXML interpreter called Elvira. During
the development and use of Elvira our team faced some problems with VoiceXML
and we also collected some remarks. We would appreciate any comments
concerning the following issues.

Here is the third part of VoiceXML comments from the Elvira development
team. This part is focused on scoping issues.

VoiceXML is a scoped language. Not only variables are scoped, but also
grammars, event handlers, etc. We understand it as a basic and essential
(and very good) idea. However the VoiceXML specification sometimes ignores
its importance.

7 - FIA description and scopes
The FIA is described in that way, that a <form> is entered and then
a complicated process is started - the whole <form>'s subtree is considered to
be "flat" and it should be processed from one point. It leads to some strange
situations related to scopes, for sample:

<cite chapter="Appendix C">
  if ( the form item execution resulted in an event )
        Find the appropriate catch for the event
        starting in the scope of the current form item.
        Execute the catch (this may leave the FIA).


We are currently in the <form>'s scope and we should look for something in the
descendant's scope. It is non-standard behavior for a computer language.

In Elvira we use the following sequence as a part of FIA:
1. open a new scope for the form item
2. execute the form item.
3. process events
4. close the scope for the form item

It results in the same behavior because in the "standard" FIA, events are
processed in the beginning of the process phase. "Our" process phase begins
before the scope is closed, thus it is simple to find appropriate event
handlers in the scope of the field item.

8 - order of <filled> calls
After the change of the order of <filled> calls, <filled> cannot be processed
in the same natural "scoped" way as event handlers.

<cite chapter="2.4">
   After each gathering of the user's input, all the fields mentioned in the
   input are set, and then the interpreter looks at each <filled> element in
   document order (no preference is given to ones in fields vs. ones in the

Why there is a change of preferences in VoiceXML 2.0 against 1.0? All other
ordering algorithms in VoiceXML use the rule "scope of active item first".
The latter rule is much more natural for computer languages and is also more
logical and easier for implementation. The currently proposed rule breaks the
scope chain and in our opinion doesn't bring any advantages.

9 - Grammars with document scope
It is only a speculation, but wouldn't be more inteligible to have document
scoped grammars physically placed under <vxml> element and the grammars would
have an attribute with id of the form which should be entered when the grammar
is matched?

It is the same case as <link>. It is simple to see, what part of the document
the link is active for. It would be nice to have the same knowledge about
grammars at the first sight.

This idea follows the "principle of locality", which is also related to the
scope issues - "everything in the document should be placed on the place,
where it is used." It could be also helpful for some visualisation tools.

    We would be very grateful for any relevant comments

            Best regards

                Pavel Cenek
                member of Elvira development team

  Pavel Cenek   Ph.D. student           email: xcenek@fi.muni.cz
  Laboratory of Speech and Dialogue  homepage: http://www.fi.muni.cz/~xcenek
  Faculty of Informatics, MU Brno    lab page: http://www.fi.muni.cz/lsd

  Currently affiliated with Norut IT           http://www.itek.norut.no/itek/
  Tromsoe, Norway as guest researcher
  Elvira - LSD VoiceXML interpreter         http://gin2.itek.norut.no/elvira/
  Engine for building dialogue applications
Received on Friday, 19 April 2002 03:44:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:03:46 UTC