W3C home > Mailing lists > Public > www-voice@w3.org > July to September 2002

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

From: Scott McGlashan <scott.mcglashan@pipebeach.com>
Date: Wed, 25 Sep 2002 16:14:20 +0200
Message-ID: <2764A29BE430E64A92EB56561587D2E7107FA1@se01ms02.i.pipebeach.com>
To: <matthew@mjwilson.demon.co.uk>
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 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,


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

  "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

2) Issues you raised and responses

In http://lists.w3.org/Archives/Public/www-voice/2002AprJun/0066.html
you raised 
the following issues which were registered as dialog change request
Our response is given inline after each issue.
1. The index between Appendix N and Appendix P appears to be Appendix
zero, not
   Appendix O.

VBWG: Accepted.

Corrected in [5].

2. In section 6.5, "Time Designations", the example "+1.5s" still
   the text, which describes the format as "an unsigned number followed
by an
   optional time unit identifier".

VBWG Response: Accepted.

Clarified in section 6.3 of [5] that a time designator is a non-negative
number which 
must be followed by ms or s (i.e. it is fully aligned with Time in

3. Section "Input Items" says that "implementations must handle
   <object> element by throwing error.unsupported.object.objectname if
   particular platform-specific object is not supported". Section 2.3.5
   "OBJECT" says that "implementations must handle the <object> element
   throwing error.unsupported.object if the particular platform-specific
   is not supported" (i.e. it does not include the object name in the
   name).  Section 5.2.6 "Event Types" does not list any
   error.unsupported.object events, but does include
   which is raised if "The requested resource has ... e.g. an
unsupported ...
   object type". Could this be clarified?

VBWG Response: Accepted.

Changed and clarified in sections and 2.3.5 of [5] that if an
does not support a specific object, it throws
error.unsupported.objectname. In section 5.2.6 of [5] that the event
error.unsupported.format is not thrown for unsupported 
object types. The section 5.2.6 is not intended as an exhaustive list of
types (no change).

4. Events such as error.unsupported.uri, error.unsupported.language,
    error.unsupported.format are ambiguous, since they could also be
    occurrences of error.unsupported.<element> if incorrect elements
    been used in the VoiceXML document.

VBWG Response: Accepted

We will clarify 5.2.6 by adding that <element> in
error.unsupported.<element> refers to "elements defined in this
specification." (not in [5]).

5. Section says that "VoiceXML allows the author to control the
   policy for each use of each resource." Is this true of the
application root

VBWG Response: Accepted

We will clarify in that there is no markup mechanism to specify
the caching policy on a root document. (not in [5]).

6. Regarding the "builtin" URI scheme,
   http://www.w3.org/Addressing/schemes#unreg says that "Unregistered
   should not be deployed widely and should not be used except
   Is there any intention to register the "builtin" scheme?

VBWG Response: Accepted.

We are still trying to determine if there is an existing URI scheme
which we can reuse 
for VoiceXML builtin. If we are unable to find one, then we will
register the builtin scheme.

7. There is a typo "attibute" in the schema in Appendix O (in the
   xsd:annotation for the Accept.attrib attributeGroup).

VBWG Response: Accepted.

corrected in [5].

8. The "minimal Conforming VoiceXML document" in appendix F1 is not
minimal. As
   the text itself states, the XML declaration, and the xmlns:xsi and
   xsi:schemeLocation are not rqeuired for conformance.

VBWG Response: Accepted.

In appendix F, changed description of example so that it is not
described as minimal.

9. Section 5.1.3 says, when referring to XML-escaping characters such as

<, >, and & :

"For clarity, examples in this document do not use XML escapes."

I strongly disagree with this decision. I think that having examples in
spec which do not work is more likely to lead to confusion than anything

else. If there is a lack of clarity in VoiceXML in places, then I
the spec should not try to hide the fact.

VBWG Response: Accepted.

Removed this text and updated all examples to escaped XML characters in
Received on Wednesday, 25 September 2002 10:15:29 UTC

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