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

RE: More W3C VXML specs feedback

From: Scott McGlashan <scott.mcglashan@pipebeach.com>
Date: Wed, 26 Jun 2002 17:18:54 +0200
Message-ID: <2764A29BE430E64A92EB56561587D2E7107E09@se01ms02.i.pipebeach.com>
To: "Guillaume Berche" <guillaume.berche@eloquant.com>, <www-voice@w3.org>


thank you very much for your detailed comments. They are much
appreciated by the team. 

Since these comments arrived after the official comment period I cannot
guarantee that they will be address within the 2.0 timeframe, but we
will try our best!

thanks again

[VoiceXML Dialog team leader]

-----Original Message-----
From: Guillaume Berche [mailto:guillaume.berche@eloquant.com]
Sent: Tuesday, June 25, 2002 16:12
To: www-voice@w3.org
Subject: More W3C VXML specs feedback


Following are some more comments on the VXML W3C Working Draft from 24
2002. I understand the time frame for comments ended May 24, 2002 but I
though they might still be useful (at least to discuss with
if they are not considered for the 2.0 official release).

Concerning event catching algorithm:

1) Precise the execution of catch handlers in section "5.2.2 Catch"
Section "5.2.2 Catch" seems to imply that handlers are called
"If a <catch> element contains a <throw> element with the same event,
there may be an infinite loop:
<catch event="help">
   <throw event="help"/>
Suggested text addition: "The FIA appendix C details the execution after
catch element is executed (in its definition of the "execute" term)"

2) Precise the definition of "execution" in the FIA appendix C to
executables from handlers.
Suggested text modification:
To execute executable content - either a block, a filled action, or a
set of
filled actions. If an event is thrown during execution, the execution of
executable content is aborted. The appropriate event handler is then
executed, and this may cause control to resume in a form item, in the
iteration of the form's main loop, or outside of the form. If a
computed-directed transition element(such as <goto>, <link>, <return> or
<submit>) is executed, the transition takes place immediately, and the
remaining executable content is not executed. During the execution of
event handler, the same rule applies as for the execution of executable
content described above (with respect to execution abortion and

3) Precise error handling during document initialization (e.g. in
document-level <script> and <var> elements)
Suggested modification:
Move the modified following text from section "5.2.6 Event Types" to
"5.2.2 Catch" (or to a new section, as suggested in comment #4)
"Errors encountered during document loading, including transport errors
document found, HTTP status code 404, and so on) and syntactic errors
<vxml> element, etc) result in a badfetch error event raised in the
document, while errors after loading (including document initialization)
(such as semantic errors during <script> and <var> initialization), are
raised and handled in the document itself."

I could not understand the rationale behind the following statement in
section "5.2.6 Event Types", near to error.badfetch.
"Whether or not variable initialization is considered part of executing
new document is platform-dependent." Can please someone explain why this
behavior would be platform dependent?

4) Precise document initialization
As described above in comment #3, some events are handled at document
initialization. However, since elements are initialized in document
events handlers may not yet be active at the time an event is thrown.
for instance the usual case of a vxml document starting with a script
element: no document handlers are yet initialized, and an error in the
<script> element would not be handled by defined event handlers.

Suggested modification: add a specific section concerning document
initialization similar to the FIA which precise the order of element

"1.5.0 Document initialization

Document initialization starts once the transport and XML schema
has been performed.

As described in section "5.2.2 Catch", errors occuring during this phase
raised and handled in the document itself. During handling of events,
variable scope chain may not be complete (there might be no chained
scope yet), but the _event shadown variable is still defined in an
variable scope"

Each element is initialized in document order including event handlers.
Consequently, it is advised to define document-level handlers first in

Once all elements are initialized, the document execution begins. As
described in section "1.5.1 Execution within One Document", document
execution begins at the first dialog by default.

5) Refine anonymous variable scope during event handling
Section "5.2.2 Catch" states that "The catch element's anonymous
scope includes the special variable _event which contains the name of
event that was thrown."
To me, this implies that the handler is invoked when the FIA is
running (that is a form and a form item are active). However, this might
be the case for events handled during document initialization.
the variable scope chain as described in section "5.1.2 Variable Scopes"
would not work, in particular there would no chained dialog scope.
Suggested modification is included in comment #4

Other feedback

6) Precise that a <field> item without implicit nor explicit grammar
throw an error.semantic event.
See if it is possible to refine the schema to enforce this.
Alternative suggested text modification to the end of section "2.3.1
"[...] The use of <option> does not preclude the simultaneous use of
<grammar>. The result would be the match from either 'grammar', not
the occurence of two <grammar> elements in the same <field> representing
disjunction of choices. However, a field item without implicit nor
grammar would result in an error.semantic event to be thrown at document
initialization time".

I hope this can help. Any comment on this is welcome.

Best regards,

Guillaume Berche
Eloquant, ZA Le malvaisin
38240 Le Versoud, France
+33 04 76 77 46 92
Received on Wednesday, 26 June 2002 11:13:10 UTC

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