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

Thank you for your comments on LCWD. Your issues have been registered
(including the change to [3]) and we will get back to you over the next
few weeks with our response.

thanks again 

Scott McGlashan 

Dialog team leader, VBWG

-----Original Message-----
From: Guillaume Berche [mailto:guillaume.berche@eloquant.com]
Sent: Tuesday, May 28, 2002 20:15
To: Scott McGlashan
Cc: www-voice@w3.org
Subject: 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 Wednesday, 5 June 2002 04:08:28 UTC