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

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

From: Scott McGlashan <scott.mcglashan@pipebeach.com>
Date: Wed, 9 Oct 2002 13:38:07 +0200
Message-ID: <2764A29BE430E64A92EB56561587D2E7107FCA@se01ms02.i.pipebeach.com>
To: "Guillaume Berche" <guillaume.berche@eloquant.com>
Cc: <www-voice@w3.org>

Guillaume,

my apologies - I sent you the response before I had completed writing
for points [4] onwards. You will receive an complete updated version
later today and we can take it from there.

thanks for your time,

Scott

 

-----Original Message-----
From: Guillaume Berche [mailto:guillaume.berche@eloquant.com]
Sent: Tuesday, October 01, 2002 10:47
To: Scott McGlashan
Cc: www-voice@w3.org
Subject: RE: [dialog] Berche - VBWG official response to VoiceXML 2.0
Last Call Review Issues


Scott,

Thanks for your response.

> Please indicate before 3 October 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.

For points 1,2,3 I am overall satisfied with the VBWG's resolutions,
even
though I regret that the modifications made to the draft specifications
are
not made public by the VBWG. It is not possible to reviewers to properly
validate corrections brought to the specifications without having access
to
their wording (the references [4] and [5] in the public response of the
VBWG
are not publicly available, thereby making the response to public
reviewers
incomplete).

For points 4,5,6,6,7,8, and 9 I can not find the corresponding VBWG's
resolution in your answer. So unless this is due to a typing problem, I
am
not satisfied with the VBWG's resolutions and wish to register an
objection
(especially for points 7 and 8).

Please let me know if more detailed information concerning the issues I
raised would help.

Thanks and best regards,

Guillaume Berche.

> -----Original Message-----
> From: www-voice-request@w3.org [mailto:www-voice-request@w3.org]On
> Behalf Of Scott McGlashan
> Sent: mercredi 25 septembre 2002 16:15
> To: guillaume.berche@eloquant.com
> Cc: www-voice@w3.org
> Subject: [dialog] Berche - 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.
>
> 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 13 September
> 2002 draft of the VoiceXML 2.0 [5].
>
> Please indicate before 3 October 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 3 October, 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
>
> -----------------------------------------------
> 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-20020913.htm
> (members only)
> (http://www.w3.org/Voice/Group/2002/WD-voicexml20-20020913.zip)
(members
> only)
>
>
> -----------------------------------------------
> 2) Issues you raised and responses
> -----------------------------------------------
>
> In http://lists.w3.org/Archives/Public/www-voice/2002AprJun/0079.html
> you raised
> the following issues which were registered as dialog change request
> R477.
> Our response is given inline after each issue.
>
> Here are some comments that I previously sent to the list concerning
the
> October 2001 draft version and that I believe to be still valid on the
> draft
> from 24 April 2002. As you suggested in our private email
conversation,
> I
> resubmit the updated list of comments with detailed suggested changes
to
> the
> text.
>
> [1]
> In Section 4.1.8, it seems incorrect to state that "While in the
> transitioning
> state various prompts are queued, [...] by the <prompt> element in
field
> items" since the queuing of prompt elements in field items is part of
> the FIA
> collect phase (Appendix C), which itself is part of the waiting phase
> ("the
> waiting state is entered in the collect phase of a field item").
>
> Prefered suggested fix: modify comments in Appendix C so that there is
a
> "prepare" phase in which prompts are queued and grammars are
activated.
> The
> "Collect" phase would then only start after the comment "// Execute
the
> form
> item."
>
> Then modify section 4.1.8 to the following:
> "The waiting and transitioning states are related to the phases of the
> Form
> Interpretation Algorithm as follows:
> - the waiting state is entered in the collect phase of an input item,
> and
> - the transitioning state encompasses the process, select and
> **prepare**
> phases"
>
> I believe this additional FIA phase makes the definition of the
waiting
> and
> transitioning more clear.
>
> Alternative fix: modify section 4.1.8 to the following:
> The waiting and transitioning states are related to the phases of the
> Form
> Interpretation Algorithm as follows:
> - the waiting state is entered in the collect phase of an input item
> **at
> the point at which the interpreter waits for input**
> - the transitioning state encompasses the process and select phases,
the
> collect phase for control items (such as <block>s), and the collect
> phase
> for input items up until the point at which the interpreter waits for
> input.
>
> VBWG Response: Rejected
>
> The queueing of prompts is part of the collect phase of the FIA, but
the
>
> collect phase is part of BOTH the waiting state and the transition
> state,
> per the description in 4.1.8. However, we have clarified in section
> 4.1.8
> of [5] the relationship between entering the waiting state and the
> phases
> of the FIA ("the waiting state is eventually entered in the collect
> phase
> of an input item (at the point at which the interpreter waits for
> input)").
>
>
> [2]
> In section 4.1.5, when playing prompt with a false bargein
> attribute, are matching DTMF or speech input buffered or discarded?
> Suggested fix: in section 4.1.5, modify the text to
> "When the bargein attribute is false, any DTMF input buffered in a
> transition state is deleted from the buffer (Section 4.1.8 describes
> input
> collection during transition states). In addition, while in the
waiting
> state and a prompt whose bargein attribute is false, any user input
> (speech
> or DTMF) is simply ignored."
>
> VBWG Response: Accepted.
>
> Clarified in section 4.1.5 of [5] that when a prompt's "bargein"
> attribute is false, no input is buffered while the prompt is playing
> (any DTMF already buffered is discarded).
>
>
> [3]
> It is not clear whether DTMF input which does not match currently
active
> grammars should interrupt a prompt whose bargein attribute is true
> Suggested fix: In section 4.1.5, correct the the first sentence with
the
> following:
>
> "If an implementation platform supports barge-in, the application
author
> can
> specify whether a user can interrupt, or "barge-in" on, a prompt using
> speech or DTMF input. In the case of DTMFs, any input (even not
matching
> active grammar) will interrupt a prompt, and will be handled in the
same
> way
> as non matching DTMFs entered outside of a prompt."
>
> VBWG Response: Accepted.
>
> We have a slightly different solution, though. We have clarified in
> section 4.1.5.1 in [5] that the "bargeintype" attribute of <prompt>
> applies to DTMF input as well as speech input
>
>
> [4]
> Just clarify 4.1.5 with respect to interruption of a chain of
> queued prompts
> Suggested fix: in section 4.1.5, modify the text to:
> "Users can interrupt a prompt whose bargein attribute is true, but
must
> wait
> for completion of a prompt whose bargein attribute is false. In the
case
> where several prompts are queued, the bargein attribute of each prompt
> is
> honored during the period of time in which that prompt is playing. If
> bargein occurs during any prompt in a sequence, all subsequent prompts
> are
> not played **(even those whose bargein attribute are set to false)**."
>
> [5]
> For completeness and convenience, an extract from section 4.1.5 below
> should
> be reproduced or at least mentionned in section 4.1.8.
> Suggested fix: add the sentence below before "Before the interpreter
> exits
> all ..."
> "As stated in section 4.1.5, when the bargein attribute is false, any
> DTMF
> input buffered in a transition state is deleted from the buffer"
>
> [6]
> Concerning ECMAScript variables holding non-scalar values (such as
field
> item variable for a record fieldaudio, or the special _prompt variable
> as
> mentionned in my previous mail)
> - what ECMAScript type do they have? Is it indeed an ECMAScript an
host
> object as defined in the ECMAScript specifications (or Array object
> containing other objects in the case of the _prompt variable). If so,
> what
> is their exact list of properties along with their type and properties
> (ReadOnly, DontEnum, DontDelete, Internal)?. As a side-question, what
> does
> the ECMAScript typeof operator returns on these objects?
>
> Concerning ECMAScript special variables (such as <name>$.<shadow_var>
in
> fields)
> - can they be modified by (of as a side effect of) ECMAScript code
> evaluation (such as evaluating a guard condition, or an expr
attribute)?
>
> Suggested fix: Add a specific section about ECMAScript evaluation.
This
> section could precise runtime error that occur during ECMAScript
> evaluation,
> possible side-effects of ECMAScript evaluation (such as cond attribute
> evaluation), and also the type of shadow variables with the text
below:
> "Shadow variables are host objects as defined in the ECMAScript
> specifications. The properties of these shadow variables are
read-only.
> Any
> attempt by some ECMAScript code evaluation (either in a script element
> or as
> a side effect of the evaluation of an expr attribute) to modify those
> properties will result in an error.semantic to be thrown"
>
> [7]
> Section 2.2 describes that the _prompt special variable "is the
choice's
> prompt". The type of this variable is fuzzy and the specs does precise
> the
> behavior of <value expr="_prompt"/> in case where a choice element
would
> contain mixed audio prompts and TTS.
>
> Suggested fix: add the following text to section 2.2 in the enumerate
> element section:
> "This specifier may refer to two special variables: _prompt is the
> choice's
> prompt, and _dtmf is the choice's assigned DTMF sequence. The _prompt
> special variable is a host object which has no visible properties and
> should
> only be used within a <value expr="_prompt"> element. If the choice
> contained more than one prompt element (such as TTS elements, or a
> nested
> <value> element) then executing the <value expr="_prompt"> would queue
> all
> of the prompt elements and would also execute the nested <value>
> element. If
> the nested <value> element references itself the _prompt variable,
this
> would lead to an infinite recursive loop, that interpreter may detect
> and
> handle by throwing an error.semantic event. The _dtmf special variable
> is of
> type string and may be used as such by ECMAScript code within the expr
> attribute of the <value> element."
>
> [8]
> Clarification to FIA with respect to run-time errors:
> When the evaluation of a guard condition results in a run-time
> exception,
> how does this modify the FIA. The FIA algorithm in appendix C seems to
> only
> consider exceptions generated during the execution phase and remains
> fuzzy
> about those that occur during previous phases (such as initialization,
> queuing of prompts such as <value>, evaluation of guard condition)
>
> Suggested fix: modify the FIA so that it state that "any runtime error
> occuring during the select phase (e.g. runtime error to evaluate guard
> condition), collect phase (e.g. runtime error at prompt queuing for
> instance
> during <value> element execution) up to the input collection result in
> the
> control being directly passed onto the process phase."
>
>
> [9] In the FIA, appendix C, for the collection of active grammars
> when not modal, it says that these include "elements up the
<subdialog>
> call
> chain." This seems to be in contradiction with the section on
> <subdialog>
> which says each subdialog has a totally separate context from the
> caller,
> and shares/inherits absolutely no elements with it.
> Suggested fix: Remove the "and then elements up the <subdialog> call
> chain."
> from the FIA description.
>
Received on Wednesday, 9 October 2002 07:39:46 GMT

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