Last updated $Date: 2009/04/22 17:09:42 $
Copyright © 2009 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
The VoiceXML 2.0 Recommendation was produced by the W3C Voice Browser Working Group as part of the activity of the W3C Interaction Domain and has been maintained as part of the activity of the W3C Ubiquitous Web Domain.
This document lists known errata and updates to the Recommendation.
Please send general comments about this document to the public mailing list at [email protected]. The archive for the list is accessible online.
Added text marked new, added text. Changed text marked changed text. Removed text marked deleted text.
Assertion 81: "If an application root document specifies an application root element error.semantic is thrown."
The assertion tests the scenario: An error is thrown when a document A transitions to root B where root B is itself referencing another root. There are three possible actions:
The text and test specify that the proper action is to throw error.semantic where a root application page has an application specified; however, it is not clear at which level it should be thrown. According to §5.3.7 "Note that for errors which occur during a dialog or document transition, the scope in which errors are handled is platform specific"
Most implementations tested in the VoiceXML Forum's Platform Certification Program pass the test as written -- e.g. throw error.semantic.
The VBWG decided that this should be left as stated: throw error.semantic, but not specify where the error is thrown.
A change request has been filed for VoiceXML 3.0.
Assertion 1106 states: "When no
A possible contradiction exists with §2.1.5.1:
"The form item's prompt will be played even if it has already been
visited. "
Example implementations:
In §5.3.6
"reprompt element"
"..., the FIA does not generally perform the normal selection and queuing of prompts on the next iteration following the execution of a catch element."
There are two exceptions listed, and assertion 1106 does not match either of those cases. From the pseudo-code in Appendix C:
unless ( the last loop iteration ended with
a catch that had NO ,
and the active dialog was NOT changed )
{
Select the appropriate prompts for an input item or .
Queue the selected prompts for play prior to
the next collect operation.Increment an input item's or 's prompt counter.
}
There are multiple interpretations of execution behavior; this will be addressed in VoiceXML 3.0.
Assertion 588:
"If the http-equiv attribute is set to "expires" and the content attribute is set to "0", the interpreter MUST not cache the document."
The definition of references the HTML 4
specification, §7.4.4 contains the reference to .
While the VoiceXML 2.0 Recommendation is ambiguous, (nearly) all
implementations tested in the VoiceXML Forum's Platform Certification
Program are consistent.
The HTML 4.0 reference is to be replaced by the HTTP1.1 specification
(RFC2616). The http-equiv feature is not inherently linked to meta (it
isn't really metadata). If an implementation supports meta and
http-equiv, it must support it as described.
A change request has been filed for VoiceXML 3.0.
Clarification: The use of "character input" in "user actions (e.g. spoken or character input received, disconnect)" and all other instances in the specification is clarified as "DTMF key input."
Add term to Glossary:
character input
Replace
The form item's prompt will be played even if it has already been visited.
with
Although several factors may affect whether or not form item prompts are queued for playing (see Section 5.3.6, for example), whether or not the form item has been previously visited will not affect whether prompts are queued.
The 'charset' attribute serves two functions: it informs the application server which character encoding is desired by the VoiceXML browser and it provides a default value for the character encoding when none is otherwise available. Scripts, unlike XML documents such as SRGS grammars, do not internally specify a character encoding.
When the protocol of the 'src' attribute allows, best practice dictates that the 'charset' attribute be used in content negotiation. The HTTP 1.1 protocol, for instance, provides the 'Accept-charset' header on request to inform the server which character encoding is desired. HTTP 1.1 dictates that if the server is unable to provide this encoding, it SHOULD return an HTTP 406 error message (corresponding to error.badfetch.http.406) though it MAY alternatively provide a response in a different character set.
The document returned upon dereferencing the 'src' attribute will often have an associated media type and an associated charset value. The VoiceXML browser is responsible for deciding whether these are acceptable. Although not required by the VoiceXML 2.0 specification, it is suggested in accordance with RFC 4329 and the IANA registry that only the 'application/javascript' and 'application/ecmascript' types be accepted by the