Re: VBWG official response to VoiceXML 2.0 Last Call Review Issues

The DOM Working Group accepts the resolution of these issues, realizing 
that it is too late in the timetable of the Voice Browser Working Group 
to do more than acknowledge that the event processing model is not 
aligned with that of XML Events or the DOM Level 2 or 3 events models. 
 We appreciate the effort of the VBWG to understand, address, and 
discuss these issues.  As we have discussed, we expect the following to 
occur as the Voice Browser specification goes forward.

1.  When reviewing the VoiceML specification for advancement, W3C should 
be aware that the incompatibilities exist between the models, considered 
out of scope for the current specification due to keeping the general 
structure of VoiceML 1.0, etc. as justified by the VBWG.

2.  Key members of the VBWG should review the DOM Level 3 Events 
specification when it reenters last call in a few weeks.  This is the 
last scheduled revision to DOM Events.  Any desired accomodation (that 
is possible without breaking DOM Level 2 compatibility etc.) to enable 
or improve compatibility of some future version of Voice ML must be 
quickly defined.

3.  The DOM WG expects to consult with the VBWG on achieving DOM 
compatibility (in these and other areas) in future versions of VoiceML, 
which should begin in the requirements phase.

Thanks,

Ray Whitmer
W3C DOM
rayw@netscape.com

Scott McGlashan wrote:

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

Received on Wednesday, 23 October 2002 12:01:11 UTC