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

Scott,

Thanks for your response and for taking time to process my comment. Your
response is satisfactory to me and you can close this comment.

Thanks again,

Guillaume.

> -----Original Message-----
> From: www-voice-request@w3.org [mailto:www-voice-request@w3.org]On
> Behalf Of Scott McGlashan
> Sent: mercredi 13 novembre 2002 16:51
> To: Guillaume Berche
> Cc: w3c voice (E-mail)
> Subject: 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 11:34:35 UTC