W3C home > Mailing lists > Public > www-voice@w3.org > October to December 2002

[dialog] Guillaume #4 - VBWG official response to VoiceXML 2.0 Last Call Review Issues

From: Scott McGlashan <scott.mcglashan@pipebeach.com>
Date: Tue, 22 Oct 2002 13:19:12 +0200
Message-ID: <2764A29BE430E64A92EB56561587D2E7108032@se01ms02.i.pipebeach.com>
To: <guillaume.berche@eloquant.com>
Cc: "w3c voice (E-mail)" <www-voice@w3.org>



The Voice Browser Working Group (VBWG) has almost
finished resolving the issues raised during the last call
review of the 24 April 2002 VoiceXML 2.0 [1]. Our apologies that 
it has taken so long to respond.

Although your comment was sent clearly outside the official comment
period, 
this is the VBWG's formal response to the issues you raised,
which have been logged in the Working Group's issues list [4].
The VBWG's resolutions have been incorporated into the 18 October
2002 draft of the VoiceXML 2.0 [5]. 

Please indicate before 1st November 2002 whether you are satisfied with
the VBWG's resolutions, whether you think there has been a
misunderstanding, or whether you wish to register an objection.
If you do not think you can respond before 1st November, please let me
know. The Director will appreciate a response whether you agree
with the resolutions or not.

Below you will find:

 1) More information follows about the process we are following.
 2) A summary of the VBWG's responses to each of your issues.

Thank you,

Scott
Co-Chair, VBWG

-----------------------------------------------
1) Process requirement to address last call issues
-----------------------------------------------

Per section 5.2.3 [2] of the 19th July 2001 Process Document, in
order for the VoiceXML 2.0 to advance to the next state (Candidate
Recommendation), the Working Group must "formally address all
issues raised during the Last Call review period (possibly
modifying the technical report)." Section 4.1.2 of the Process
Document [3] sets expectations about what constitutes a formal
response:

  "In the context of this document, a Working Group has formally
  addressed an issue when the Chair can show (archived) evidence
  of having sent a response to the party who raised the
  issue. This response should include the Working Group's
  resolution and should ask the party who raised the issue to
  reply with an indication of whether the resolution reverses the
  initial objection."

If you feel that the response is based on a misunderstanding of
the original issue, you are encouraged to restate and clarify the
issue until there is agreement about the issue, so that the
Working Group may prepare its substantive response.

If the response shows understanding of the original issue but
does not satisfy the reviewer, you may register a formal
objection with the Working Group that will be carried forward
with the relevant deliverables. 

[1] http://www.w3.org/TR/2002/WD-voicexml20-20020424/
[2] http://www.w3.org/Consortium/Process-20010719/tr.html#RecsCR
[3] http://www.w3.org/Consortium/Process-20010719/groups.html#WGVotes
[4] http://www.w3.org/Voice/Group/2002/voiceXML-change-requests.htm
(members only)
[5] http://www.w3.org/Voice/Group/2002/WD-voicexml20-20021018.htm
(members only)
(http://www.w3.org/Voice/Group/2002/WD-voicexml20-20021018.zip) (members
only)

-----------------------------------------------
2) Issues you raised and responses
-----------------------------------------------
In http://lists.w3.org/Archives/Public/www-voice/2002AprJun/0104.html
you raised 
the following issues which were registered as dialog change requests
R495. 
Our response is given inline after each issue.

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)"

VBWG Response: Rejected.

Unclear what the problem is: we don't see any inconsistency between the
5.2.2 text and the FIA. 


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 forms 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)."

VBWG Response: Accepted.

We have already clarified execution of executable context in response to
other requests in [5]. Note that <link> cannot appear in executable
context.


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?


VBWG Response: Accepted.

In [5], we have added the following text to the 5.2.6: "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. Errors that occur after loading and before entering
the initialization phase of the Form Interpretation Algorithm are
handled in a platform-specific manner. Errors that occur after entering
the FIA initialization phase, such as semantic errors, are raised in the
new document. The handling of errors encountered during the loading of
the first document in a session is platform-specific."

Variable initiatization may be platform-dependent since a platform may
use a SAX-based document construction technique where initiation of
variables takes places as each statement is reached during document
loadin, or may use a DOM-based technique where the whole document is
constructed first, then any initialization takes place. 

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


VBWG Response: Accepted.

We have clarified in [5] in the FIA Appendix the description of
initialization:

"foreach ( <var>, <script> and form item, in document order )
   if ( the element is a <var> )
     Declare the variable, initializing it to the value of
     the "expr" attribute, if any, or else to undefined.
   else if ( the element is a <script> )
     Evaluate the contents of the script if inlined or else
     from the location specified by the "src" attribute.
   else if ( the element is a form item )
     Create a variable from the "name" attribute, if any, or
     else generate an internal name.  Assign to this variable
     the value of the "expr" attribute, if any, or else
     undefined."

and clarified error handling during FIA execution:


"During FIA execution, events may be generated at several points. These
events are processed differently depending on which phase is active.

Before a form item is selected (i.e. during the Initialization and
Select phases), events are generated at the dialog level. The
corresponding catch handler is located and executed. If the catch does
not result in a transition from the current dialog, FIA execution will
terminate.

Similarly, events triggered after a form item is selected (i.e. during
the Collect and Process phases) are usually generated at the form item
level. There is one exception: events triggered by a dialog level
<filled> are generated at the dialog level. The corresponding catch
handler is located and executed. If the catch does not result in a
transition, the current FIA loop is terminated and Select phase is
reentered."


Note that XML Schema validation is NOT compulsory in VoiceXML (see
Appendix F - Conformance). 


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


VBWG Response: Rejected.

We don't see the 'implication' that the existent of the _event variable
implies the FIA is currently running. 


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


VBWG Response: Rejected.

The specification doesn't state or imply that a field without grammars
is an error, so we cannot make it more precise.
Received on Tuesday, 22 October 2002 07:19:15 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 30 October 2006 12:48:56 GMT