RE: Comments on VoiceXML 2.0 Working Draft 23rd October 2001

Hi Matthew,

sorry for the delay in getting you this offical responses.

Below is our reponse to your questions (indicated by >>>). 

If you are not satisfied with the reply, or want more information, let
me know.


(Chairman, W3C VB Dialog Committee)

-----Original Message-----
From: Matthew Wilson []
Sent: 12 December 2001 23:54
Subject: Comments on VoiceXML 2.0 Working Draft 23rd October 2001

Some comments on the VoiceXML 2.0 Working Draft:

1. None of the examples are conforming, according to Appendix F, because

none of them have a namespace declaration.

>>> This will be corrected in the next draft. 

2. Section 1.5.1. Since "lang" has been replaced with "xml:lang" between

VoiceXML 1.0 and 2.0, why has "base" not been replaced with "xml:base"?

>>> This will be added in the next draft.

3. The glossary does not include entries for:
a) the term "energy", one of the possible values for bargeintype

>>> energy" will no longer be a bargein type in the next draft. However,
energy and SSML will still be needed and so will be added to the
glossary in the next draft. 

4. The URI scheme for telephone numbers has changed from "phone:" in 
VoiceXML 1.0 to "tel:" in VoiceXML 2.0, but this is not listed in
Appendix J.

>>> This will be corrected in the next draft. 

5. There is no explicit statement of what a VoiceXML 2.0 processor
do when it finds a VoiceXML 1.0 document. Presumably it would be allowed
switch to a backwards-compatibility mode?

>>> This specification covers 2.0. The next draft will describe more
clearly that the behavior of Conforming 2.0 processor is undefined when
it encounters elements and attributes not defined in the 2.0 namespace.
So, it could support VoiceXML 1.0 as platform-specific behavior. 

6. Are ECMAScript objects passed to a subdialog passed by value or by 

>>> The next draft will clarify that <param> values are passed by value
in subdialogs. 

7. Section 1.2.4, point 4: "The language has a well-defined
should be "The language has well-defined semantics..."

>>> This will be corrected in the next draft. 

8. Would it be helpful for the HTTP User-Agent to indicate which version
VoiceXML the browser understands? Or is there a better mechanism for
I'm thinking about a scenario where a server is prepared to serve up 
different documents for a VoiceXML 1.0 or a VoiceXML 2.0 processor - is 
there any provision for this?

>>> We will investigate this under the issue of 'capability
interrogation' in a later version of the specification.

9. Section 1.2.4, point 1: "For details about XML, refer to the
XML Specification". This should refer (at least primarily) to XML 1.0 
Second Edition, The
XML Specification is (at the time of writing) based on XML 1.0 1st

>>> This will be corrected in the next draft. 

10. I don't think there is any mention of a MIME type for VoiceXML.

>>> This will be added in the next draft. 

11. In Appendix F, "propriety" should be "proprietary".

>>> This will be corrected in the next draft. 

12. Also in Appendix F, there is a reference to a conforming processor 
throwing 'an "error.unsupported.<element>" event'. Should there also be
reference to "error.unsuppported.<attribute>", in the event of a
using an unknown attribute as part of a known element?

>>> An element with an illegal attribute according to the VoiceXML 2.0
namespace, will be treated as an element without the VoiceXML 2.0
namespace. We are working to clarify this as part of the conformance
appendix hopefully in the next draft. 

13. Section 5.2.6, Event Types says

"Errors encountered during document loading" ... "and syntactic errors
XML header, no <vxml> element, etc) result in a badfetch error event"...

I'm not sure what the XML header referred to here is. If it is the XML 
declaration, then I don't believe that its omission is an error. (XML
says "XML documents should begin with an XML declaration which specifies

the version of XML being used.")

>>> This will be corrected in the next draft. Its omission is an error
if the document character encoding is neither UTF-8 or UTF-16. 

Matthew Wilson

Received on Saturday, 16 February 2002 18:31:50 UTC