RE: Comments on the VoiceXML 2.0 Working Draft 24 April 2002

Sorry about extra traffic, I've made a mistake in my previous mail in
Comment #3 whose suggested text change should read:

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

Regards,

Guillaume.

> -----Message d'origine-----
> De : www-voice-request@w3.org [mailto:www-voice-request@w3.org]De la
> part de Guillaume Berche
> Envoyé : mardi 28 mai 2002 20:15
> À : Scott McGlashan
> Cc : www-voice@w3.org
> Objet : Comments on the VoiceXML 2.0 Working Draft 24 April 2002
>
>
> Scott,
>
> 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.
>
> Comment #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.
>
>
> Comment #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."
>
> Comment #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, only input that matches an
> active grammar will interrupt a prompt, non matching DTMFs will
> be silently
> ignored."
>
> Comment #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)**."
>
> Comment #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”
>
> Comment #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"
>
> Comment #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."
>
> Comment #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."
>
>
> Comment #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.
>
> I hope those comments can help. Any feedback is appreciated,
>
> Best regards,
>
> Guillaume Berche.
> ------------------------------------------
> Guillaume Berche
> Eloquant, ZA Le malvaisin
> 38240 Le Versoud, France
> guillaume.berche@eloquant.com
> +33 04 76 77 46 92
> ------------------------------------------
>

Received on Thursday, 30 May 2002 06:32:22 UTC