W3C home > Mailing lists > Public > www-voice@w3.org > January to March 2005

VBWG official response to last call issue

From: MattO <matto@tellme.com>
Date: Fri, 11 Mar 2005 16:08:01 -0800
To: <duerst@w3.org>
Cc: <www-voice@w3.org>, <w3c-i18n-ig@w3.org>
Message-ID: <005601c52697$8e236a50$f59c9dd1@sea.tellme.com>

Dear Martin, et al,

The Voice Browser Working Group (VBWG) has almost finished resolving the
issues raised during the last call review of the 28 July 2004 working draft
of VoiceXML 2.1 [1]. Our apologies that it has taken so long to respond.

Please indicate before March 17th, 2005 if you are satisfied with the VBWG's
resolutions, if you think there has been a misunderstanding, or if you wish
to register an objection. If you will be unable to respond before March
17th, please let me know. The Director will appreciate a response whether or
not you agree with the resolutions.

Below you will find:

 1) More information follows about the process we are following.
 2) A summary of the VBWG's response to your issues.

Thank you,

Matt Oshry
Chief Editor, VoiceXML 2.1

1) Process requirement to address last call issues

Per section 7.2 [2] of the 5th February 2004 Process Document, in order for
the VoiceXML 2.1 specification to advance to the next state (Candidate
Recommendation), the Working Group must "Formally address all issues raised
about the document since the previous step." 
Section 3.3.3 of the Process Document [3] sets expectations about what
constitutes a formal response:

  "In the context of this document, a group has formally addressed an issue 
  when it has sent a substantive response to the reviewer who raised the
  A substantive response is expected to include rationale for decisions 
  (e.g., a technical explanation, a pointer to charter scope, or a pointer 
  to a requirements document). The adequacy of a response is measured
  what a W3C reviewer would generally consider to be technically sound. 
  If a group believes that a reviewer's comments result from a
  the group SHOULD seek clarification before reaching a decision."

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/2004/WD-voicexml21-20040728/
[2] http://www.w3.org/2004/02/Process-20040205/tr.html#transition-reqs
[3] http://www.w3.org/2004/02/Process-20040205/policies.html#formal-address

2) Issues you raised and responses
In http://lists.w3.org/Archives/Public/www-voice/2004OctDec/0032.html you
raised the following issues which were registered as change request R107.
Our response is given inline:

"Abstract: 'VoiceXML 2.1 specifies a set of features commonly implemented by

Voice Extensible Markup Language platforms. This specification is designed 
to be fully backwards-compatible with VoiceXML 2.0 [VXML2].'

-> It is not clear to the reader quickly enough that this specification
    only describes a diff between VoiceXML 2.1 and VoiceXML 2.0. This
    should be made much clearer."

VBWG Response: Accepted
A sentence was added to the abstract to indicate that the specification
describes only the set of additional features. In addition a table of the
elements that were added or enhanced was added to the introduction.

"Appendix C: 'A conforming VoiceXML document is a well-formed [XML] document

that requires only the facilities described as mandatory in this 
specification and in [VXML2].'

-> Similar confusion as above. Either VoiceXML 2.1 is the diff, or it is
    the result of additions. But not both."

VBWG Response: Rejected
While the VoiceXML 2.1 specification describes only the set of additional
features that have been frequenty requested and widely implemented -
VoiceXML 2.1 is built on top of the foundation described in the VoiceXML 2.0
specification. A conforming VoiceXML 2.1 document is one that meets the
requirements described in both the VoiceXML 2.0 and VoiceXML 2.1

"Section 2, street example: In usual Web browsers, for internationalization
reasons, usually 'address1', 'address2', are used. Is there such practice
for Voice applications? If not, how are addresses in various locations
around the world handled? It would be highly desirable if this example were
fixed so that it could be used as good practice worldwide. Same for

VBWG Response: Rejected
While the language supports the construction of a dialog that allows the
user to specify a location anywhere in the world, the working group feels
that extending the existing sample code to demonstrate that functionality
would complicate the example unnecessarily. The purpose of the example is to
demonstrate concisely how to set the srcexpr attribute on grammar.

"URIs: The XML Schema at
containing the segment:

<xsd:simpleType name='URI.datatype'>
         <xsd:documentation>URI (RFC2396)</xsd:documentation>
     <xsd:restriction base='xsd:anyURI'/>

seems to try to restrict anyURIs used in VXML to URIs only. However, there
are two problems with this approach:
1) This is a very poor way of trying to make this restriction,
    if the restriction is indeed to be made, an actual pattern
    should be specified.
2) Such a restriction would rule out the use of IRIs, which would
    be a very bad idea with respect to internationalization.
So we request that you:
- (possibly) add a restriction that just removes space and a few
   other ASCII characters allowed in anyURI, but neither in
   URIs nor in IRIs.
- Say clearly in the spec that wherever the term URI is used,
   this isn't restricted to ASCII only, but follows IRIs."

VBWG Response: Deferred

VoiceXML 2.1 (VXML21) is designed to be completely backwards compatible with
VoiceXML 2.0 (VXML2). The VXML21 schema is derived directly from the VXML2
schema, and the definition of "URI.datatype" is identical. The VBWG suggests
that it would be more appropriate to submit this particular CR to the VBWG
as a proposed errata for VXML2. If the CR were adopted for VXML2, the change
would be picked up by VXML21 to maintain compatibility.
Received on Saturday, 12 March 2005 00:08:31 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:07:38 UTC