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

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 18 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 18 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)**."

VBWG Response: Accepted.

Edit applied in [5].


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

VBWG Response: Rejected.

We didn't see a clear use case or motivation for this change. 

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

VBWG Response: Rejected Suggested Fix.

Many questions here!

The properties of ECMAScript variables in VoiceXML are not specified
unless necessary. 

With <record>, we have clarified in [5] that its implementation is
platform-dependent (so different implementations can have different
ECMAScript properties) but that all must playable by <audio>,
submittable by <submit> and so on as described in the specification. 

For shadow variables, we have clarified in [5] that they are writable,
so they can be modified.

For runtime errors encountered during the FIA, we have clarified that in
the FIA Appendix of [5]. 


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

VBWG Response: Rejected.

The assumption that the <choice> element can contain SSML is no longer
true: in [5] a <choice> element can now only contain CDATA.  

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

VBWG Response: Accepted.

Clarified in [5] that FIA handles run-time errors in all phases.

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

VBWG Response: Accepted.

Edit applied in [5].

_______________

Scott McGlashan
 
PIPEBEACH
Box 24035/Linnégatan 89 B, 7tr
SE-104 50 Stockholm, Sweden
fax:       +46 8 54590993
office:    +46 8 54590990



www.pipebeach.com

Received on Wednesday, 9 October 2002 09:52:57 UTC