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

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

From: Guillaume Berche <guillaume.berche@eloquant.com>
Date: Wed, 13 Nov 2002 17:35:44 +0100
To: "Scott McGlashan" <scott.mcglashan@pipebeach.com>
Cc: "w3c voice (E-mail)" <www-voice@w3.org>
Message-ID: <ELEGLIHGLLIBFPCIGAKGOELMDAAA.guillaume.berche@eloquant.com>

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 GMT

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