Last updated $Date: 2009/04/22 17:09:42 $
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 firstname.lastname@example.org. 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 <reprompt> is used in conjunction with a <goto nextitem> within an error handler, then the target form item's prompt will not be played."
A possible contradiction exists with §18.104.22.168:
"The form item's prompt will be played even if it has already been
"..., 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.
"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 <meta> references the HTML 4
specification, §7.4.4 contains the reference to <meta>.
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:
The form item's prompt will be played even if it has already been visited.
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.
A conflict exists between the use of the term "will" (improper term) vs. "may" in the following sections:
§ 3.1.4 Activation of Grammars
"Grammar activation is not affected by the inputmodes property. For instance, if the inputmodes property restricts input to just voice, DTMF grammars will may still be activated, but cannot be matched."
§ 6.3.6 Misc. Properties ---definition of "inputmodes" property in Table 63.
"…voice-only grammars may be active when the inputmode is restricted to DTMF. Those grammars would not be matched, however, because the voice input modality is not active."
All uses of the term "flush" as in "Flush the prompt queue" are to be interpreted as "Play all queued prompts to completion."
... After the audio queue is flushed, the outgoing call is initiated. ...
... After all queued prompts are played to completion, the outgoing call is initiated. ...
...Processing the <disconnect> element will also flush the prompt queue (as described in Section 4.1.8). ...
... Processing the <disconnect> element will also play all queued prompts to completion (as described in Section 4.1.8). ...
The W3C Voice Browser Working Group has applied to IETF to register a media type for VoiceXML. The requested media type is application/voicexml+xml.
The W3C Voice Browser Working Group has adopted the convention of using the ".vxml" filename suffix for VoiceXML documents.
The media type for VoiceXML is application/voicexml+xml, as defined by RFC4267 [RFC4267]: W3C Speech Interface Media Types. RFC4267 also assigns the filename suffix '.vxml' for VoiceXML documents.
and add to M.1 normative references:
Interface Framework Media Types ", IETF RFC
The VoiceXML 2.0 schema. The RestrictedVariableName datatype defined in vxml-datatypes.xsd has been corrected to allow '$' within the variable name:
<xsd:documentation>Variable name which doesn't start with "_"
or number, doesn't end with '$' and doesn't contain ".".
Additional constraints: must follow ECMAScript variable naming
conventions; not include ECMAScript reserves words</xsd:documentation>
XML 1.0 is replaced by XML 1.1.
Extensible Markup Language (XML) 1.1 (Second Edition), T. Bray et al. World Wide Web Consortium, 16 August 2006, edited in place 29 September 2006. This version of the XML 1.1 Recommendation is http://www.w3.org/TR/2006/REC-xml11-20060816/. The latest version is available at http://www.w3.org/TR/xml11/.
URLs are replaced by IRIs.
Internationalized Resource Identifiers (IRIs),
M. Duerst and M. Suignard, Editors. IETF, January 2005. This RFC is
available at http://www.ietf.org/rfc/rfc3987.txt
Replace "queueing" with "queuing"
Code example original text (spelling error)
<prompt> Please say Social Securityy number.</prompt>Replace with:
<prompt> Please say Social Security number.</prompt>
|Assertion ID||Spec section||Abstract|
|89||1.5.4||A VoiceXML interpreter may continue executing even after it no longer has a connection to the user.|
|552||5.3.11||When the interpreter executes a disconnect element, it must drop the call.|
|553||5.3.11||When the interpreter executes a disconnect element, it must throw a catchable connection.disconnect.hangup event.|
Assertion 89 implies the disconnect event would get queued. Assertion 553 implies the disconnect event would be thrown immediately.
To clarify what's described in §5.3.11:
Upon entering the waiting state, prompts cannot be played but queueing is possible. There's a difference between prompts that are queued before the event was thrown, and those that are queue afterwards. The prompts queued before are played to completion; those queued afterward are not played because the connection no longer exists. Once the interpreter has entered the final processing state, the interpreter cannot go back to the waiting state (though the application can keep throwing events and catching them).
Note: Disconnect only occurs while the interpreter is in the waiting state.