[dialog] Guillaume #5 - VBWG official response to VoiceXML 2.0 Last Call Review Issues

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.

Although your comment was sent clearly outside the official comment
period, 
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 18 October
2002 draft of the VoiceXML 2.0 [5]. 

Please indicate before 1st November 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 1st November, 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
Co-Chair, VBWG

-----------------------------------------------
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-20021018.htm
(members only)
(http://www.w3.org/Voice/Group/2002/WD-voicexml20-20021018.zip) (members
only)

-----------------------------------------------
2) Issues you raised and responses
-----------------------------------------------
In http://lists.w3.org/Archives/Public/www-voice/2002AprJun/0109.html
you raised 
the following issues which were registered as dialog change requests
R496. 
Our response is given inline after each issue.

) Problem with section "1.5.4 Final Processing"

This section states that "While in the final processing state the
application must remain in the transitioning state and may not enter the
waiting state (as described in Section 4.1.8). Thus for example the
application should not enter <field>, <record>, or <transfer> while in
the
final processing state. The VoiceXML interpreter must exit if the
VoiceXML
application attempts to enter the waiting state while in the final
processing state.
"

While section "4.1.8 Prompt Queueing and Input Collection" states
"Similarly, asynchronously generated events not related directly to
execution of the transition should also be buffered until the waiting
state
(e.g. connection.disconnect.hangup). "
However, since a single event triggers a transition to the
transitionning
state, those two descriptions conflict.
Imagine the following situation in which a remote user sends a bunch of
DTMFs and then hangs up, then since events would be sent in sequence,
and
that input would normally trigger a transition to another field which
then
requests a input collection. As currently described in section "1.5.4
Final
Processing", this would result in the interpreter exiting, without
letting
the application catch the connection.disconnect.hangup event.

Suggested modification to section "1.5.4 Final Processing":

The final processing state is entered when the
connection.disconnect.hangup
event is handed to the application. As described in section "4.1.8
Prompt
Queueing and Input Collection", the remote user may be disconnected and
DTMF
may be provided from a previous buffer before the application receives
the
connection.disconnect.hangup event. During the period of time in which
the
remote user is disconnected and final processing state is not yet
entered,
the application may queued prompts and request input as for normal
processing. The buffered input will be used can compared against
requested
input, only DTMF grammars terminating timeouts would be shortened.

While in the final processing state the application must remain in the
transitioning state and may not enter the waiting state (as described in
Section 4.1.8). Thus for example the application should not enter
<field>,
<record>, or <transfer> while in the final processing state (i.e while
handling the connection.disconnect.hangup event). However, the <submit>
tag
is legal. The VoiceXML interpreter must exit if the VoiceXML application
attempts to enter the waiting state while in the final processing state.

VBWG Response: Rejected.

We believe there is some confusion here. The final processing state
doesn't occur 
until the disconnect event occurs, so the problem you have identified
should not 
happen.


2) Modify section "5.3.11 DISCONNECT"
Section "5.3.11 DISCONNECT" states that "Causes the interpreter context
to
disconnect from the user. As a result, the interpreter context will
throw a
connection.disconnect.hangup event, which may be caught to do cleanup
processing, e.g."

I believe this is not a good thing to throw an event in this case
because a
catch clause would not be able to differentiate between a real user
hang-up
or some logic in the application that requested a disconnection. The
suggested cleanup phase can easily done by the application by throwing a
custom event, and in the catch clause performing necessary clean-up and
then
using the <disconnect> element.

Suggested text modification to section "5.3.11 DISCONNECT":
"As a result, the interpreter context will disconnect the remote user
and
exit the interpreter. Note that applications that would be willing to
perform tasks upon disconnection (such as clean up) may rather throw a
custom event, and in the catch clause perform necessary processing prior
to
invoke the <disconnect> element."


VBWG Response: Rejected.

The application can always tell the difference between a 'real hangup'
and 
an application generated one, since the developer can always use
scripting 
to indicate that it is application-generated (e.g. set a variable).

Received on Tuesday, 22 October 2002 07:19:16 UTC