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: Tue, 8 Mar 2005 17:35:57 -0800
To: <dom@w3.org>
Cc: <www-voice@w3.org>
Message-ID: <009001c52448$5cf43280$6401a8c0@sea.tellme.com>

Dear Dom,

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]. Although your feedback was based on the First Working
Draft, the specification did not change radically, and we have evaluated
your requests against the LCWD [1]. Our apologies that it has taken so long
to respond.

Please indicate before March 14th, 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
14th, 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/2004JulSep/0009.html you
raised the following issue which was registered as change requests R86-R94,.
Our response is given inline:

"Reviewing the VoiceXML 2.1 Draft, dated March 23rd 2004 [1] - overall a
very clear and precision document, I have spotted a few points worth of
- the conformance section of the document [2] uses terms like 'may', 'must',
'recommended', etc, but without reference to RFC 2119 nor is there any
definition of how these should be interpreted; is that on purpose?"

VBWG Response: Accepted
Definitions for these terms and a reference to RFC 2119 has been added to
the 'Status of this Document' section of the 2.1 specification.

"- the conformance labels (VoiceXML document, VoiceXML processor) don't make
references to the version of VoiceXML; is that intended?"

VBWG Response: Accepted
The Conformance appendix (C) has been updated to specify the intended
version of VoiceXML - 2.1.

"- related to this, it's not obvious from reading voicexml2.0 (nor
voicexml2.1) what a voicexml processor should do with a <vxml> document with
a version that it doesn't know; if it should throw an error, I wonder how
this relates to the claim that VoiceXML2.1 is backwards compatible with

VBWG Response: Accepted
The following text has been added to C.3: 'When a Conforming VoiceXML 2.1
Processor encounters a non-Conforming VoiceXML 2.0 or 2.1 document, its
behavior is undefined.'

"- it's not clear which sections are normative and which are simply

VBWG Response: Rejected
The sections of the document in the main body are normative unless otherwise
specified. For example, in section 9, 'Adding type to &lt;transfer&gt;' we
explicitly state 'As specified in 2.3.7 of [VXML2], the &lt;transfer&gt;
element is optional,  though platforms should support it. Platforms that
support &lt;transfer&gt; may support any combination of bridge, blind, or
consultation transfer types.' Appendices are informative unless otherwise
explicitly indicated. For example, in Appendix B and Appendix C: 'This
section is Normative.' In Appendix F.1, the title is 'Normative References'.

"- the notion of XML well-formed document is bound to XML 1.0 in the spec;
is there any discussion on accepting also XML 1.1?"

VBWG Response: N/A
The VBWG is currently investigating the feasibility of resolving this issue.
We will get back to you with an official response within a week.

"- the references to XML 1.0 are outdated (latest version is from February

VBWG Response: Accepted
The reference to XML 1.0 has been updated to point to the 3rd edition
published in Feb 2004.

"- this may be planned for an more advanced draft, but having a table with
all the elements and attributes defined by VoiceXML 2.1 would be great (like
in HTML 4.01 [3])"

VBWG Response: Accepted
A table of elements has been added to the introduction (1.1).

"- the example in section 9.3 is not well-formed (missing ending '>' in the
root element) [this was found out by extracting the examples from the spec
using an XSLT [4]; when the schema/dtd are published, it would be nice to
re-use this trick to check that the examples and the formal languages are in

VBWG Response: Accepted
The example code has been fixed.

"Some input on one of the specific issues that the document raises: -
data_sec: is there any reason why this is done in a processing instruction?
process instructions aren't very scalable, have an odd place in the XML
infoset, among other things... It looks to me like this security mechanism
would be better addressed in a different place altogether - e.g. it would be
more scalable to have a way to link to a security policy, rather than (or in
addition to?) embedding in the document itself."

VBWG Response: Accepted
The VBWG evaluated a number of mechanisms that would enforce the security of
the data retrieved by the <data/> element. In comparison with other
mechanisms, the VBWG concluded that the processing instruction is
lightweight and therefore straightforward for data providers and platform
vendors to understand and to implement. The VBWG acknowledges, however, that
it is one of several legitimate mechanisms for enforcing security, and the
group has decided to make its description in the spec informative.
Received on Wednesday, 9 March 2005 01:36:38 UTC

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