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 Tuesday, 28 May 2002 14:20:05 UTC