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

Guillaume,

thanks for your response.

In response to your comment re. point 3, we will make the change you
suggest 
in the FIA appendix extract replacing 'form items' with 'input items'.

Let me know if this is satisfactory, so I can close this official
response.

thanks

Scott
 

-----Original Message-----
From: Guillaume Berche [mailto:guillaume.berche@eloquant.com]
Sent: Wednesday, October 30, 2002 17:37
To: Scott McGlashan
Cc: w3c voice (E-mail)
Subject: 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, 13 November 2002 10:52:14 UTC