W3C home > Mailing lists > Public > www-voice@w3.org > July to September 2002

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

From: Scott McGlashan <scott.mcglashan@pipebeach.com>
Date: Wed, 25 Sep 2002 16:14:32 +0200
Message-ID: <2764A29BE430E64A92EB56561587D2E7107FA3@se01ms02.i.pipebeach.com>
To: <guillaume.berche@eloquant.com>
Cc: <www-voice@w3.org>

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,


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

  "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

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
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
from 24 April 2002. As you suggested in our private email conversation,
resubmit the updated list of comments with detailed suggested changes to

In Section 4.1.8, it seems incorrect to state that "While in the
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
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.
"Collect" phase would then only start after the comment "// Execute the

Then modify section 4.1.8 to the following:
"The waiting and transitioning states are related to the phases of the
Interpretation Algorithm as follows:
- the waiting state is entered in the collect phase of an input item,
- the transitioning state encompasses the process, select and

I believe this additional FIA phase makes the definition of the waiting
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
Interpretation Algorithm as follows:
- the waiting state is entered in the collect phase of an input item
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
for input items up until the point at which the interpreter waits for

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
per the description in 4.1.8. However, we have clarified in section
of [5] the relationship between entering the waiting state and the
of the FIA ("the waiting state is eventually entered in the collect
of an input item (at the point at which the interpreter waits for

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
collection during transition states). In addition, while in the waiting
state and a prompt whose bargein attribute is false, any user input
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).

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

"If an implementation platform supports barge-in, the application author
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
as non matching DTMFs entered outside of a prompt."

VBWG Response: Accepted.

We have a slightly different solution, though. We have clarified in
section in [5] that the "bargeintype" attribute of <prompt>
applies to DTMF input as well as speech input

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
for completion of a prompt whose bargein attribute is false. In the case
where several prompts are queued, the bargein attribute of each prompt
honored during the period of time in which that prompt is playing. If
bargein occurs during any prompt in a sequence, all subsequent prompts
not played **(even those whose bargein attribute are set to false)**."

For completeness and convenience, an extract from section 4.1.5 below
be reproduced or at least mentionned in section 4.1.8.
Suggested fix: add the sentence below before "Before the interpreter
all ..."
"As stated in section 4.1.5, when the bargein attribute is false, any
input buffered in a transition state is deleted from the buffer"

Concerning ECMAScript variables holding non-scalar values (such as field
item variable for a record fieldaudio, or the special _prompt variable
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,
is their exact list of properties along with their type and properties
(ReadOnly, DontEnum, DontDelete, Internal)?. As a side-question, what
the ECMAScript typeof operator returns on these objects?

Concerning ECMAScript special variables (such as <name>$.<shadow_var> in
- 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
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.
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"

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
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
prompt, and _dtmf is the choice's assigned DTMF sequence. The _prompt
special variable is a host object which has no visible properties and
only be used within a <value expr="_prompt"> element. If the choice
contained more than one prompt element (such as TTS elements, or a
<value> element) then executing the <value expr="_prompt"> would queue
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
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."

Clarification to FIA with respect to run-time errors:
When the evaluation of a guard condition results in a run-time
how does this modify the FIA. The FIA algorithm in appendix C seems to
consider exceptions generated during the execution phase and remains
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
during <value> element execution) up to the input collection result in
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>
chain." This seems to be in contradiction with the section on
which says each subdialog has a totally separate context from the
and shares/inherits absolutely no elements with it.
Suggested fix: Remove the "and then elements up the <subdialog> call
from the FIA description.
Received on Wednesday, 25 September 2002 10:15:31 GMT

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