RE: More W3C VXML specs feedback

Guillaume,

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

Scott
[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



Hello,

Following are some more comments on the VXML W3C Working Draft from 24
April
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
practitionners
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
synchronously:
"If a <catch> element contains a <throw> element with the same event,
then
there may be an infinite loop:
<catch event="help">
   <throw event="help"/>
</catch>"
Suggested text addition: "The FIA appendix C details the execution after
a
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:
"execute
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
the
executable content is aborted. The appropriate event handler is then
executed, and this may cause control to resume in a form item, in the
next
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
the
event handler, the same rule applies as for the execution of executable
content described above (with respect to execution abortion and
transition)."

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
section
"5.2.2 Catch" (or to a new section, as suggested in comment #4)
"Errors encountered during document loading, including transport errors
(no
document found, HTTP status code 404, and so on) and syntactic errors
(no
<vxml> element, etc) result in a badfetch error event raised in the
calling
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
the
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
order,
events handlers may not yet be active at the time an event is thrown.
Take
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
initializations

"1.5.0 Document initialization

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

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

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

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
variable
scope includes the special variable _event which contains the name of
the
event that was thrown."
To me, this implies that the handler is invoked when the FIA is
currently
running (that is a form and a form item are active). However, this might
not
be the case for events handled during document initialization.
Consequently,
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
should
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
FIELD"
"[...] The use of <option> does not preclude the simultaneous use of
<grammar>. The result would be the match from either 'grammar', not
unlike
the occurence of two <grammar> elements in the same <field> representing
a
disjunction of choices. However, a field item without implicit nor
explicit
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
guillaume.berche@eloquant.com
+33 04 76 77 46 92
------------------------------------------

Received on Wednesday, 26 June 2002 11:13:10 UTC