W3C home > Mailing lists > Public > www-voice@w3.org > October to December 2002

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

From: Scott McGlashan <scott.mcglashan@pipebeach.com>
Date: Wed, 9 Oct 2002 16:26:29 +0200
Message-ID: <2764A29BE430E64A92EB56561587D2E7107FCF@se01ms02.i.pipebeach.com>
To: <rayw@netscape.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 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
Co-Chair, VBWG; Leader VoiceXML Dialog Team

-----------------------------------------------
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
R505. 
Our response is given inline after each issue.
 

Introduction

Members of the DOM working Group have read through the Last Call draft
of the
Voice Markup Language specification, looking for issues related to the
DOM
specification.  No member of the group has actively followed the
specification, so our reading was undertaken from a position of knowing
nothing about the specification.

Here are issues we noticed that we felt should be documented.

[1] VoiceXML Events as DOM Events

Section 5.2 on event handling claims that "An interpreter may implement
VoiceXML event handling using a DOM 2 event processor".  It is difficult
to
see how this is true, and the following sub-issues are examples of why
this is
not true.

VBWG Response: Accepted.

We original believed that a modified DOM2 event processor could
implement the VoiceXML event model. However, since it is 'modified'
processor - in order to handle your points [2] and [3] - it is not
strictly a DOM2 processor. Hence, in the candidate recommendation
version, all references to the DOM2 event model will be removed (note
that they are still present in [5]).

[2] Handler Order

Later in the document, section 5.2.4 states that the event delivery
algorithm
is described as a constrained version of XML Events and DOM 2 event
processing, where the catch events are explicitly ordered by document
order.
This makes impossible to implement VoiceXML event handling using a
normal DOM
2 event processor in any reasonable fashion.

VBWG Response: Accepted.

In the candidate recommendation version, this statement will be removed.

[3] Canceling on Current Level

Also, section 5.2.4 states that an event handler which handles an event
stops
propogation of the event, and implies that other event handlers declared
on
the same element will not be called.  While DOM event handling has the
ability
to cancel handlers declared on ancestor nodes, all handlers will always
still
be called on a single node if any handlers are called on that node
regardless
of cancelling that occurs during delivery.

VBWG Response: Accepted.

In the candidate recommendation version, this statement will be removed.


[4] Interoperable ECMAScript in Compound Documents

Expect combination of VoiceXML with other markup such as, XHTML, SVG,
SSML,
etc. when defining multimodal presentations.  In such cases, ECMAScript
throughout the document should be consistent and interoperable.  In this
case,
we would expect content authors call functions in the global scope
throughout
the document and access all parts of the document through DOM, register
event
handlers, etc.

The intertwining of ECMAScript scopes and VoiceXML-based declaration of
variables visible to ECMAScript, as described in section 5.1, is
unusual.
Ignoring implementation issues, it seems like it could cause usage
problems.
For example, if a script uses DOM to add an event handler, how does the
event
handler script get access to the field values it needs to get or set to
respond to the event?  If a script tries to access or modify a field
value
through DOM, how does that relate to the in-scope variable?


VBWG Response: Accepted.

We don't expect these problems to arise in VoiceXML 2 since it was never
designed for embedding in other execution container. We are aware that
VoiceXML needs to be aligned with W3C best practises in terms of
document model, event model, and so on, but doing so in VoiceXML 2 would
be too fundamental a change this late in the process. In the next
version of the language, which is intended for embedding in other
environments, we are committed to addressing these model issues at a
fundamental level, and look forward to receiving requirements from, and
working with, on these issues with the DOM WG in the future.

_______________

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 10:26:33 GMT

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