[dialog] MMWG - 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.

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,

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/Member/w3c-voice-wg/2002May/0091.html
you raised 
the following issues which were registered as dialog change request
R469. 
Our response is given inline after each issue.


The group believes that VoiceXML would be more useful to multi-modal
interactions with the changes discussed in items 1, 2 and 3,
particularly
items 1 and 3.  We do not believe that these issues necessarily need to
be
resolved in order for the spec to progress, but we would like to hear
discussion of any plans the group has for addressing these issues.

Item 4 is just a minor correction.

1. VoiceXML Modularization
Modularization of VoiceXML would separate VoiceXML constructs into 
separate modules.  This would allow the constructs to be used in a
multimodal language
as components that can be embedded in multimodal documents.
Priority:  High

VBWG Response: Rejected. 

This issue has been deferred until the next version of VoiceXML.
Attempting to 
introduce it at this stage is problematic since it requires bringing
VoiceXML into line with XHTML modularization principles (e.g. no tag
should have non-local effects, such as determination of active grammars)
and this may require a fundamental restructuring of parts of the
VoiceXML. For the next 
version, the VBWG will take this and other MMWG requirements into
account 
from the beginning of the specification process. We encourage the MMWG
to become actively involved in the process once it is initiated.


2. NLSML
It would be useful to understand how NLSML formatted results can be used
to
populate VoiceXML field items.  The VoiceXML specification includes a
comprehensive discussion of mapping ASR results in the form of
ECMAScript
objects to VoiceXML forms, but says very little about NLSML format.
Priority:  Medium High


VBWG Response: Rejected. 

Again this has been deferred until the next version of VoiceXML. NLSML
is not mature as a specification and is currently changing into EMMA
under the auspices of the MMWG. When mature, the specification may be
re-considered for the next version of VoiceXML.

3. XML Events
A modularized VoiceXML should support XML Events.  VoiceXML components
embedded in multimodal XML documents would share a multimodal document's
DOM
and DOM
events.
Priority:  High

VBWG Response: Rejected.

Again this has been deferred until the next version of VoiceXML, where
integration with event models, such as DOM and XML, can be addressed at
a fundamental level. Feedback from the DOM WG has indicated that the
current VoiceXML event model is not compatible with the current DOM
event model.


4. Grammar tag's content model
Section 3.1.1 should state explicitly that the SRGS grammar tag is
extended
to allow PCDATA for inline grammar formats besides SRGS.  It currently
says
that SRGS tags including grammar have not been redefined.
Priority:  High

VBWG Response: Accepted 

We have clarified in Sections 3.1.1 and 3.1.1.4 of [5] that the SRGS
<grammar> 
element is extended in VoiceXML 2.0 to allow PCDATA for inline grammar
formats 
besides the XML format of SRGS.

Received on Wednesday, 25 September 2002 10:15:28 UTC