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

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

From: Scott McGlashan <scott.mcglashan@pipebeach.com>
Date: Tue, 29 Oct 2002 23:44:22 +0100
Message-ID: <2764A29BE430E64A92EB56561587D2E710805B@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 5th 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 5th 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/2002JulSep/0025.html
you raised 
the following issues which were registered as dialog change requests
R507. 
Our response is given inline after each issue.

Following are additional suggestions for clarifications of the VXML 2.0
W3C
Working Draft from 24 April 2002.

[1] Precise the behavior if Reprompt is executed outside of a catch
element

Suggested text addition to section "5.3.6 REPROMPT":
"If a Reprompt is executed outside of a catch element (such as in a
block or
filled elements) then an "error.semantic" event is thrown.

VBWG Response: Accepted Clarification/Rejected suggestion.

In the next version of the specification it will be clarified that a
<reprompt/> outside a catch has no effect (since the FIA performs normal
selection and queuing of prompts outside catches).


[2] Precise which event should be thrown for malformed ECMAScript
expressions in Var, Assign, Script, and ECMAScript expression evaluation
(such as the "cond" attribute, and expr attribute variants).

Suggested text addition to Appendix C, FIA:
"During the execution of the FIA, various ECMAScript expressions are
evaluated such as the "cond" attribute of input or prompt items and the
different variants of "expr" attribute. If the evaluation of such an
ECMAScript expression defined in the document results in an error then
an
"error.semantic" event is thrown. These events are handled in the same
way
than events thrown during execution as documented in the beginning of
this
section."

VBWG Response: Rejected.

This behavior you describe is clearly implied by a number of points
where
error.semantic is discussed; e.g. 5.2.6 error.semantic is thrown if
undefined 
variable is referenced.  We have clarified in [5] for other change
requests, 
that in '2.1.6.2.1 Select phase':

"If an error occurs while checking guard conditions, the event is thrown
which 
skips the collect phase, and is handled in the process phase."


[3] Precise that the Block's prompt queuing occurs during prior to
execute
the Block.
In the example below, it seems unclear from the specifications whether
the
second prompt would be heard because prompts are executable content and
the
definition of "execute" states that as soon as a "<goto> is executed,
the
transfer takes place immediately, and the remaining executable content
is
not executed." However, the collect phase states that appropriate
prompts
elements should be selected for the input item (including blocks).
<block>
	This is my first prompt text
	<goto next="#another_dialog"/>
	This is my second prompt text
</block>

Suggested modifications to the appendix C:
"   else if ( a <block> was chosen )
   {
       Set the block's form item variable to a defined value.

       Execute the block's executable context (except for prompts which
were
previously queued in the select phase).
   }"

VBWG Response: Rejected.

This appears to be confusion. A block is not an input item. A block's
prompts 
are not collected and queued a la prompt selection in form items. A
block is 
fully executed in collect phase; in your example, when <goto> is
executed, 
no further content is executed, so the second prompt is never executed.
Received on Tuesday, 29 October 2002 17:44:26 GMT

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