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

Scott,

Thanks for your answer and for processing my comments outside of the
official comment period. I am satisfied with the VBWG's resolutions
except for point 3 for which I wish to add the following comment.


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

Sorry about the incorrect wording, I meant that a Block is a form item and
as such it conforms to the appendix C algorithm which states in the collect
phase: "Select the appropriate prompts for the form item." and makes no
exception for the Block element.

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

I agree with that "A block is fully executed in collect phase" but as
described in the appendix C the collect phase is split into 3 steps:
1) queue prompts for the form item
2) activate grammars
3) execute form item

My feedback was to clarify the steps 1 and 3 with respects to the Block
element. If the Block's prompts are to be considered as executable content,
then I would suggest that appendix C excludes blocks from the sentence
"Select the appropriate prompts for the form item." so that there is no
ambiguity as to whether the Block's prompts are treated in step #1 or step
#3 which leads to different results as illustrated in my comment. As a
prompt is a form item, it seems a legitimate interpretation of the
specifications to queue its prompts in step#1 and only execute non-prompts
executable content in step #3.

A simple correction to the specification to remove the ambiguity would be to
replace "form item" with "input item" in the following appendix C extract:


   //
   // Collect Phase: [...]
   //
   // Queue up prompts for the form item.

   unless ( the last loop iteration ended with
            a catch that had no <reprompt> )
   {
       Select the appropriate prompts for the form item.

       Queue the selected prompts for play prior to
       the next collect operation.

       Increment the form item’s prompt counter.
   }



Please, let me know if my comment is still unclear/confusing.

Thanks and best regards,

Guillaume Berche.

> -----Original Message-----
> From: Scott McGlashan [mailto:scott.mcglashan@pipebeach.com]
> Sent: mardi 29 octobre 2002 23:44
> To: guillaume.berche@eloquant.com
> Cc: w3c voice (E-mail)
> Subject: [dialog] Guillaume #6 - VBWG official response to VoiceXML 2.0
> Last Call Review Issues
>
>
>
> 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 Wednesday, 30 October 2002 11:36:26 UTC