# VoiceXML 2.0
Implementation Report

Version: Apr 7, 2003

Contributors:

  Matt Oshry, Tellme Networks (Chief Editor)
  Ramy Adeeb, Tellme Networks
  Paolo Baggia, Loquendo
  Amos Blackman, Tellme Networks
  Michael Bodell, Tellme Networks
  David Burke, VoxPilot
  Emily Candell, Comverse
  Jerry Carter, SpeechWorks
  Pete Danielsen, Lucent
  Jonathan Engelsma, Motorola
  Mike Epstein, Tellme Networks
  Dan Evans, Nortel
  Jim Ferrans, Motorola
  Will Gardella, SAP
  Jeff Kusnitz, IBM
  Paul Lamere, Sun
  Rob Marchand, VoiceGenie
  Scott McGlashan, PipeBeach
  Ralf Pfeiffer, BeVocal
  Brad Porter, Tellme Networks
  Ken Rehor
  Laura Ricotti, Loquendo
  Davide Tosello, Loquendo

Copyright ©2003 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.

## Table of Contents

- 1. Introduction
  - 1.1 Implementation Report Objectives
  - 1.2 Implementation Report Non-objectives
- 2. Work During the Candidate Recommendation Period
- 3. Participating in Implementation Report
- 4. Entrance Criteria to PR
- 5. Implementation Report Requirements
  - 5.1 Detailed requirements for Implementation Report
  - 5.2 VoiceXML Processor Coverage
  - 5.3 Notes on Testing Speech Recognition
  - 5.4 Out of Scope
- 6. Systems
- 7. Test Results
- Appendices
  - Appendix A. Test assertion XML API definition
    - A.1 Final status indicators
    - A.2 Intermediate status indicators
    - A.3 Input operations
    - A.4 Grammar definitions
    - A.5 Grammar selection
    - A.6 Predefined utterances
    - A.7 Document Type Definition
    - A.8 Test examples
    - A.9 Sample XSLT Template Definition
    - A.10 Transformation output
  - Appendix B. Abstract CGI (IRCGI) API definition
    - B.1 Processing Model
    - B.2 Syntax
    - B.3 Document Type Definition
    - B.4 Test examples
    - B.5 Usage
    - B.6 Transformation requirements
    - B.7 Reference XSLT documents
    - B.8 Test developer requirements
    - B.9 Web server administrator requirements
  - Appendix C. Acknowledgements

## 1. Introduction

The VoiceXML 2.0 Specification entered the Candidate Recommendation period on 28 January 2003.

The planned date for entering Proposed Recommendation is 10 April 2003. Preparation of an Implementation Report is a key criteria for moving beyond the Candidate Recommendation. This document describes the requirements for the Implementation Report and the process that the Voice Browser Working Group will follow in preparing the report.

#### 1.1 Implementation Report Objectives

1. Must verify that the specification is implementable.
2. Must demonstrate interoperability of implementations of the specification.

#### 1.2 Implementation Report Non-objectives

1. The IR does not attempt conformance testing of implementations.

## 2. Work During the Candidate Recommendation Period

During the CR period, the Working Group will carry out the following activities:

1. Clarification and improvement of the exposition of the specification.
2. Disposing of Comments that were communicated to the WG during the CR period.
3. Preparation of an Implementation Report meeting the criteria outlined in this document.

## 3. Participating in Implementation Report

You are invited to contribute to the assessment of the W3C VoiceXML 2.0 Specification by participating in the Implementation Report process.

- All the tests (table below) and the report submission format are provided with this document. The whole test suite including the report submission format is also contained in irtests.zip
- Comments on this document and the test suite or requests for further information should be sent to the Working Group's public mailing list www-voice@w3.org (archive). If an updated version of this document or the test set is published, a notification will be sent to this mailing list.

## 4. Entrance Criteria to PR

The VBWG established the following entrance criteria to Proposed Recommendation in the Request for CR:

1. Sufficient reports of implementation experience have been gathered to demonstrate that VoiceXML processors based on the specification are implementable and have compatible behavior.
2. Specific Implementation Report requirements (outlined below) have been met.
3. Formal responses to all comments received by the Working Group.

## 5. Implementation Report Requirements

#### 5.1 Detailed requirements for Implementation Report

1. Testimonials from implementers will be included in the IR when provided to document the utility and implementability of the specification.
2. IR must cover all specified features in the specification. For each feature the IR should indicate:
   - Feature status: required, optional, other
   - Feature utility/usefulness based on feedback from implementers
   - Implementability of the feature specification
   - Interoperability of multiple implementations of the feature
3. Feature status is a factor in test coverage in the report:
   - Required specification features must have at least two implementations. Implementations that do not implement a required specification feature must document the reason for not implementing.
   - Optional specification features must have at least 1 implementation. Implementations that do not implement an optional specification feature should document the reason for not implementing.

#### 5.2 VoiceXML Processor Coverage

Require implementations and testimonial statements for at least two VoiceXML User Agents supporting both ASR and DTMF.

#### 5.3 Notes on Testing Speech Recognition

1. Each test contains zero or one input and corresponding outputs. The output format follows xxx. To completely perform a test the input requested by the prompt, if any, must be used.
2. A test report must indicate the outcome of each test. Possible outcomes are "pass", "fail" or "not-impl". "Pass" requires output of the VoiceXML processor that is equivalent to the output specified in the respective test file for all inputs in this test file. A report must document the way test output was verified. "Not-impl" means the VoiceXML processor has not implemented the specific feature required by a test.
3. A test report may contain an additional comment for each test. If a test fails a comment should be added (see also Detailed requirements for Implementation Report).
4. Every attempt has been made to keep the tests language-neutral through the use of the Test API described in Appendix A. When a test uses hard-coded prompts and/or hard-coded grammars, however, US English is used.
5. Some tests contain notes that should be read before executing them. These notes can be found in comments contained within the main test document and preceding the test code.

#### 5.4 Out of Scope

1. IR will not cover VoiceXML processor recognition performance.
2. IR will not cover Semantic Interpretation of grammars.

## 6. Systems

Note: The testimonials with pink background from "Acme Labs" and "Beta Inc." are just examples and will be replaced with the actually submitted testimonials.

### Acme Labs

#### Exec Summary

The W3C VoiceXML 2.0 Specification is well-written, easily implementable and extremly useful. Acme Labs used it to make waffles, to transcribe telephone calls, to chase roadrunners, and to straighten the Tower of Pisa.

### Beta Inc.

#### Exec Summary

The W3C VoiceXML 2.0 Specification is extremly useful, easily implementable and well-written. Beta Inc. used it to make waffles, to transcribe telephone calls, to chase roadrunners, and to straighten the Tower of Pisa.

## 7. Test Results

The following table lists the assertions that were gleaned from the VoiceXML 2.0 Specification. The Assertion ID column uniquely identifies the assertion and links to a corresponding test. The Spec column identifies the section of the specification from which the assertion was derived. The Required column indicates whether or not the spec requires the platform to implement the feature described by the assertion. The Automatable column indicates whether or not the associated test can be automated or requires manual execution. The Assertion column describes the assertion.

Note: An anonymous column for each company that runs the test suite will be added, and each cell will specify "pass" or "fail" to reflect actual submitted implementation results.

Assertion ID | Spec | Required | Automatable | Assertion
--- | --- | --- | --- | ---
1 | [1.2.5] | Yes. | Yes. | For each HTTP request, the interpreter identifies itself using the User-Agent header in the format "name/version".
2 | [1.2.5] | Yes. | Yes. | The interpreter must be able to freely sequence TTS and audio output.
7 | [1.2.5] | Yes. | Yes. | The interpreter must be able to receive speech recognition grammar data dynamically.
8 | [1.2.5] | Yes. | No. | The interpreter must be able to record audio received from the user.
11 | [1.3] | Yes. | Yes. | If a URI does not refer to a document, the current document is assumed.
12 | [1.3] | Yes. | Yes. | If a URI does not refer to a dialog, the first dialog is assumed.
18 | [1.3.1] | Yes. | Yes. | A menu contains choices that can define transitions when matched.
19 | [1.3.1] | Yes. | Yes. | A subdialog invokes a new dialog that once done, returns to the original context.
20 | [1.3.1] | Yes. | Yes. | Upon return to the calling context all variable instances, grammars, and state information are restored.
24 | [1.3.3] | Yes. | Yes. | An application root document's variables are defined and reachable via the application scope upon the loading of a document that specifies it as the application root.
25 | [1.3.3] | Yes. | Yes. | An application root document's variables are not reinitialized as the user transitions between documents that both specify it as the application root.
26 | [1.3.3] | Yes. | Yes. | An application root document's variables are no longer reachable from the application scope when the user transitions to a document not in that application.
27 | [1.3.3] | Yes. | Yes. | An application root document's grammars are active during each time the interpreter listens, until it is unloaded.
28 | [1.3.4] | Yes. | Yes. | A dialog can receive input matching a single grammar such that no other grammars are active.
29 | [1.3.4] | Yes. | Yes. | A dialog can receive input matching one of several active grammars.
30 | [1.3.4] | Yes. | Yes. | A user can direct interpretation in scenarios where grammars outside the current dialog are active, by matching one of these grammars, at which point execution transitions to the dialog containing the matched grammar.
32 | [1.3.5] | Yes. | Yes. | The platform can throw a semantic error upon encountering an error in VoiceXML semantics.
36 | [1.3.5] | Yes. | Yes. | Catch elements are inherited by enclosing elements by copy.
37 | [1.3.6] | Yes. | Yes. | A link specifies a grammar that is active whenever a user is in the scope of the link.
41 | [1.5] | Yes. | Yes. | A document may have meta elements.
42 | [1.5] | Yes. | Yes. | A document may have var elements.
43 | [1.5] | Yes. | Yes. | A document may have script elements.
44 | [1.5] | Yes. | Yes. | A document may have property elements.
45 | [1.5] | Yes. | Yes. | A document may have catch elements.
46 | [1.5] | Yes. | Yes. | A document may have link elements.
48 | [1.5.1] | Yes. | Yes. | The next dialog is determined by the previous dialog.
50 | [1.5.1] | Yes. | Yes. | The version attribute is required on the vxml tag.
51 | [1.5.1] | Yes. | Yes. | The xmlns attribute is required on the vxml tag.
52 | [1.5.1] | Yes. | Yes. | The xml:base attribute must be allowed on the vxml tag.
53 | [1.5.1] | Yes. | Yes. | The xml:lang attribute must be allowed on the vxml tag.
54 | [1.5.1] | Yes. | Yes. | The application attribute must be allowed on the vxml tag.
55 | [1.5.1] | Yes. | No. | The value of xml:lang must be inherited down the document hierarchy by elements which also define the xml:lang attribute and do not have an alternative value.
56 | [1.5.2] | Yes. | Yes. | The interpreter supports having an application root document and an application leaf document.
58 | [1.5.2] | Yes. | Yes. | When a leaf document causes a root document to be loaded, none of the dialogs in the root document are executed.
59 | [1.5.2] | Yes. | Yes. | Application root document variables are available for use by the leaf document.
61 | [1.5.2] | Yes. | Yes. | Common ECMAScript code can be defined in the application root and used in leaf documents.
62 | [1.5.2] | Yes. | Yes. | Application root catch handlers are default handlers for leaf documents.
72 | [1.5.2] | Yes. | Yes. | When transitioning between two leaf documents that both specify the same application fully resolved URI then the transition must preserve the application root document's variables for use by the second leaf document.
73 | [1.5.2] | Yes. | Yes. | A transition from an application leaf document to its own application root document caused by a 'goto' must preserve the application root document's variables for use by the root document.
74 | [1.5.2] | Yes. | Yes. | If a transition occurs as the result of a submit between an application leaf document and its own application root document the application root document's variables must be re-initialized.
75 | [1.5.2] | Yes. | Yes. | If a transition occurs from an application root document to itself then it must reinitialize the application root document's variables.
76 | [1.5.2] | Yes. | Yes. | If a transition occurs from an application root document to a different application root document it must initialize the new application root document and use the new application root document's variables.
77 | [1.5.2] | Yes. | Yes. | When a subdialog is invoked the original document and root document must be preserved for the completion of the subdialog.
80 | [1.5.2] | Yes. | Yes. | If a document refers to a non-existent application root document, an error.badfetch event is thrown.
81 | [1.5.2] | Yes. | Yes. | If an application root document specifies an application root element error.semantic is thrown.
82 | [1.5.3] | Yes. | Yes. | A document may contain a subdialog element.
83 | [1.5.3] | Yes. | Yes. | A document may contain a return element.
84 | [1.5.3] | Yes. | Yes. | Subdialogs add a new executable context when they are invoked.
85 | [1.5.3] | Yes. | Yes. | A subdialog can be a new dialog within the existing document.
86 | [1.5.3] | Yes. | Yes. | A subdialog can be a new dialog within a new document.
87 | [1.5.3] | Yes. | Yes. | A subdialog can be composed of several documents.
88 | [1.5.3] | Yes. | Yes. | A subdialog's new context may itself invoke a subdialog.
89 | [1.5.4] | No. | Yes. | A VoiceXML interpreter may continue executing even after it no longer has a connection to the user.
93 | [2.1] | Yes. | Yes. | A form may contain form items, which are subdivided into input items ( <field>, <record>, <transfer>, <object>, <subdialog>) and control items (<block> and <initial>).
96 | [2.1] | Yes. | Yes. | A form may contain <var> elements.
97 | [2.1] | Yes. | Yes. | A form may contain event handlers: <catch>, <error>, <help>, <noinput>, and <nomatch>.
98 | [2.1] | Yes. | Yes. | A form may contain <filled> elements.
99 | [2.1] | Yes. | Yes. | A form may specify an id attribute.
100 | [2.1] | Yes. | Yes. | A form may specify a scope attribute which specifies the default scope of the form's grammars.
111 | [2.1.6.2.3] | Yes. | Yes. | FIA ends when it encounters a <goto>.
112 | [2.1.6.2.3] | Yes. | Yes. | FIA ends when it encounters a <submit>.
113 | [2.1.6.2.3] | Yes. | No. | FIA ends when it encounters an <exit>.
114 | [2.1.6.2.3] | Yes. | Yes. | FIA ends when it encounters a <return>.
138 | [2.1.6.1] | Yes. | Yes. | The value of the name attribute of a form item defines a dialog-scoped variable that holds the value of the form item, i.e., dialog.name is a reference to the form item variable.
143 | [2.1.6.1] | Yes. | Yes. | A form item variable does not need to have a name attribute.
145 | [2.1.5] | Yes. | Yes. | A form may have one or more initial form items.
147 | [2.1.5] | Yes. | Yes. | If a form has a form level grammar, its input items can be filled in any order.
148 | [2.1.5] | Yes. | Yes. | If a form has a form level grammar, more than one input item can be filled as a result of any one user utterance.
149 | [2.1.5] | Yes. | Yes. | A form-level grammar can fill the following form items: <field>, <record>, <transfer>, <object> and <subdialog>.
152 | [2.1.6.2.1] | Yes. | Yes. | For all types of form item, if the form item is assigned a value, that form item is not eligible to be visited by the FIA (unless/until it is subsequently set to undefined).
153 | [2.1.6.2.1] | Yes. | Yes. | Using the clear tag on a form item variable will make it eligible to be visited by the FIA (provided that it does not have a cond attribute evaluating to false).
154 | [2.1.6.2.1] | Yes. | Yes. | Using the goto nextitem will force the FIA to immediately transition to the chosen form item.
163 | [2.1.6.2.1] | Yes. | Yes. | If the last main FIA loop resulted in a goto nextitem or goto expritem then the specified form item is selected.
165 | [2.1.6.2.1] | Yes. | No. | If the last main FIA loop did not result in a goto nextitem and there is no form item which is eligible to be visited then an implicit exit is generated.
183 | [2.1.6.2.3] | Yes. | Yes. | If in the collect phase an event occurs the appropriate catch element is identified and executed in the process phase.
185 | [2.1.6.2.3] | Yes. | Yes. | If an event handler, executed after an event is thrown while processing a form item, transfers control with a <goto> or <submit>, the FIA resumes in the new form at the initialisation phase.
186 | [2.1.6.2.3] | Yes. | Yes. | If an event handler, executed after an event is thrown while processing a form item, does not transfer control with a <goto> or <submit> the FIA resumes in the current form at the selection phase.
187 | [2.1.6.2.3] | Yes. | Yes. | If an input from the collect phase matches a link than the associated link's transition is executed if present.
188 | [2.1.6.2.3] | Yes. | Yes. | If an input from the collect phase matches a link than the associated link's event is thrown if present.
189 | [2.1.6.2.3] | Yes. | Yes. | If a link throws an event the event is processed in the context of the current form item.
190 | [2.1.6.2.3] | Yes. | Yes. | If an input matches a grammar in a form other than the current form, then the FIA terminates and the other form is initialized.
192 | [2.1.6.2.3] | Yes. | Yes. | If an input matches a grammar in a form other than the current form then that form's FIA starts with this input in its process phase.
195 | [2.1.6.2.3] | Yes. | Yes. | If an input matches a grammar in the form then each identified filled action is executed in document order.
197 | [2.1.6.2.3] | Yes. | Yes. | While executing a filled, processing of filled actions continues after a <reprompt>.
198 | [2.1.6.2.3] | Yes. | Yes. | If an event is thrown during the execution of a <filled>, event handler selection starts in the scope of the <filled>, which could be a form item or the form itself, and then proceeds outward by enclosing dialog scopes.
200 | [2.2] | Yes. | Yes. | If a menu is given an id attribute, the menu can be referenced using goto.
201 | [2.2] | Yes. | Yes. | If a menu's scope attribute is set to "dialog", the menu's grammars are active only when the user transitions into the menu.
202 | [2.2] | Yes. | Yes. | If a menu's scope attribute is set to "document", the menu's grammars are active over the whole document (or if the menu is in the application root document, any loaded document in the application).
203 | [2.2] | Yes. | Yes. | If a menu's dtmf attribute is set to "true", the first nine choices that have not explicitly specified a value for the dtmf attribute are given the implicit ones "1", "2", etc. Remaining choices that have not explicitly specified a value for the dtmf attribute will not be assigned DTMF values (and thus cannot be matched via a DTMF keypress).
204 | [2.2] | Yes. | Yes. | The dtmf attribute of choice can specify a sequence of DTMF digits. Whitespace is ignored.
205 | [2.2] | Yes. | Yes. | When the DTMF associated with the choice is matched, the appropriate action is taken based on the next, expr, event or eventexpr attribute.
206 | [2.2] | Yes. | Yes. | When the accept attribute of choice is set to "exact", or is not set and the accept attribute of its enclosing menu is set to "exact", or neither choice's accept attribute nor menu's is set, then the text of the choice element defines the exact phrase to be recognized. The user must say the entire phrase in the same order in which it occurs in the choice element phrase for matching this element.
207 | [2.2] | No. | Yes. | When the accept attribute of choice is set to "approximate", or is not set and the accept attribute of its enclosing menu is set to "approximate", then the text of the choice element defines an approximate recognition phrase, as defined under "Grammar Generation" in section 2.2.
208 | [2.2] | Yes. | Yes. | Exactly one of the next, expr, event, and eventexpr attributes must be specified. Otherwise an error.badfetch event is thrown.
209 | [2.2] | Yes. | Yes. | When the grammar associated with a choice element is matched, the URI associated with the "next" or "expr" element is fetched and transitioned to.
210 | [2.2] | Yes. | Yes. | When the grammar associated with a choice element is matched, the event associated with the event or eventexpr attribute is thrown.
211 | [2.2] | Yes. | Yes. | When "next" or the result of "expr" is not a correct URI, error.badfetch is thrown.
212 | [2.2] | Yes. | Yes. | The message attribute defines a string that is available as the variable _message inside a catch element that catches the event being thrown.
213 | [2.2] | Yes. | Yes. | The messageexpr attribute is an ECMAScript expression evaluating to the variable _message inside the catch element which catches the event being thrown.
215 | [2.2] | Yes. | Yes. | If a grammar element is specified in choice, then the external grammar is used instead of an automatically generated grammar.
216 | [2.2] | Yes. | No. | The enumerate element without content inside a prompt lists all the choices, following the order in which they appear in the menu.
217 | [2.2] | Yes. | No. | The enumerate element with content defines a template specifier that will list all the choices. Two special variables are defined
218 | [2.2] | Yes. | No. | An enumerate element can be used inside prompts associated with a menu element.
219 | [2.2] | Yes. | No. | An enumerate element can be used inside catch element elements associated with a menu element.
220 | [2.2] | Yes. | No. | An enumerate element can be used inside prompts associated with a field element that contain option elements.
221 | [2.2] | Yes. | No. | An enumerate element can be used inside catch element elements associated with a field element that contain option elements.
222 | [2.2] | Yes. | Yes. | If an enumerate element is used elsewhere, an error.semantic event is thrown.
223 | [2.2] | Yes. | Yes. | Grammar matches within menu will update the application.lastresult$ array.
224 | [2.2] | Yes. | No. | If the event handler called after matching a choice with an event or eventexpr attribute does not cause the interpreter to exit or transition control, then the FIA will clear the form item variable of the menu's anonymous field, causing the menu to be executed again.
232 | [2.3.1] | Yes. | Yes. | The variable associated with the name attribute of the field holds the recognition result.
233 | [2.3.1] | Yes. | Yes. | The named variable associated with the field must be unique among form items in the form; otherwise, error.badfetch is thrown.
234 | [2.3.1] | Yes. | Yes. | If specified, the value of the expr attribute is evaluated and serves as the form item variable's initial value.
235 | [2.3.1] | Yes. | Yes. | The default value of the expr attribute is ECMAScript undefined.
236 | [2.3.1] | Yes. | Yes. | If the form item is initialized to a value via evaluation of the expr attribute, the form item will not be visited unless the form item variable is cleared.
237 | [2.3.1] | Yes. | Yes. | If the cond attribute is present and its value evaluates to boolean false, the field is not visited.
238 | [2.3.1] | Yes. | Yes. | The form item can also be visited if the cond attribute is not specified.
239 | [2.3.1] | No. | Yes. | The type attribute, if present, specifies the name of one of the following builtin grammar types from Appendix P: boolean, date, digits, currency, number, phone, time.
240 | [2.3.1] | Yes. | Yes. | The value of the slot attribute defines the name of the grammar slot used to populate the form item variable of the field.
241 | [2.3.1] | Yes. | Yes. | If the slot attribute is absent, the interpreter uses the value associated with the name attribute of the field to map the grammar slot to the form item variable.
242 | [2.3.1] | Yes. | Yes. | If the value of the modal attribute is false, all active grammars are turned on while collecting this field.
243 | [2.3.1] | Yes. | Yes. | If the value of the modal attribute is true, then only the field's grammars are enabled, and all other grammars are temporarily disabled.
244 | [2.3.1] | Yes. | Yes. | The field element exposes a shadow variables named confidence, utterance, inputmode, and interpretation. The values of the utterance and inputmode shadow variables correspond to the values of the corresponding properties of the first object in the application-scoped lastresult$ array.
245 | [2.3.1] | Yes. | Yes. | The confidence shadow variable is the confidence level for the name field of this interpretation and may range from 0.0-1.0. A value of 0.0 indicates minimum confidence, and a value of 1.0 indicates maximum confidence.
246 | [2.3.1.1] | Yes. | Yes. | A field may contain a grammar element whose src attribute can specify an absolute or relative URI.
247 | [2.3.1.1] | Yes. | Yes. | A grammar can be specified inline.
248 | [2.3.1.1] | Yes. | Yes. | error.badfetch is thrown if a grammar specifies a src attribute and an inline grammar.
250 | [2.3.1.2] | No. | Yes. | A builtin URI of the form "builtin:grammar/<type>" references a builtin speech grammar.
251 | [2.3.1.2] | No. | Yes. | [optional] A builtin URI of the form "builtin:dtmf/<type>" references a builtin DTMF grammar.
252 | [2.3.1.2] | No. | Yes. | [optional] A field containing two builtin grammar elements, one referring to the builtin speech grammar and the other referring to the builtin DTMF grammar of the same type is equivlent to a field whose type attribute is set to the equivalent type.
254 | [2.3.1.3] | Yes. | Yes. | The PCDATA contained by an option element within a field generates a speech grammar.
255 | [2.3.1.3] | Yes. | Yes. | When an option is chosen, the value attribute determines the interpretation value for the field's shadow variable and for application.lastresult$.
256 | [2.3.1.3] | Yes. | Yes. | The dtmf attribute of an option element defines the DTMF sequence required for the option to be selected.
257 | [2.3.1.3] | Yes. | Yes. | When the accept attribute of an option element is set to "exact", the PCDATA of the option defines the exact phrase to be recognized for the option to be selected.
258 | [2.3.1.3] | Yes. | Yes. | Both option and grammar elements may be specified within a field.
259 | [2.3.2] | Yes. | Yes. | The interpreter executes content contained in the block.
260 | [2.3.2] | Yes. | Yes. | The interpreter visits the block when the cond attribute evaluates to true and the form item variable associated with the block is undefined.
261 | [2.3.2] | Yes. | Yes. | The interpreter ignores the block when the form item variable associated with the block is defined via expr.
262 | [2.3.2] | Yes. | Yes. | The interpreter ignores the block when the form item variable associated with the block is set via an assign.
263 | [2.3.4] | Yes. | Yes. | The interpreter executes the subdialog associated with the src or srcexpr attribute.
267 | [2.3.4] | Yes. | Yes. | If the called subdialog is in a separate document then variables from the calling document, and dialog scope are inaccessible to the subdialog.
268 | [2.3.4] | Yes. | Yes. | The variables passed to the subdialog via the <param> element are accessible as variables within the dialog scope of the invoked subdialog. A <param> overrides the corresponding <var> expr attribute which is ignored.
269 | [2.3.4] | Yes. | Yes. | The interpreter throws error.badfetch after the specified fetchtimeout when the URL associated with the src or srcexpr attribute points to a non-existent resource.
270 | [2.3.4] | Yes. | Yes. | Exactly one of "src" or "srcexpr" must be specified; otherwise, an error.badfetch event is thrown.
271 | [2.3.4] | Yes. | Yes. | If the subdialog returns a namelist, the filled element contained by the subdialog is executed upon return from the subdialog.
272 | [2.3.5] | Yes. | Yes. | If an object element refers to an unknown object, the error.unsupported.objectname event is thrown.
273 | [2.3.6] | Yes. | No. | Any DTMF keypress matching an active grammar terminates recording.
274 | [2.3.6] | Yes. | No. | DTMF keypresses not matching an active grammar are ignored (and therefore do not terminate or otherwise affect recording).
275 | [2.3.6] | Yes. | Yes. | If the termination grammar matched is a local DTMF grammar, the recording is placed in the record variable.
277 | [2.3.6] | Yes. | Yes. | The variable associated with the name attribute references the recorded audio, and the audio can be played back using audio expr.
278 | [2.3.6] | Yes. | Yes. | The variable associated with the name attribute of the record element can be submitted via the namelist of the submit element. The submitted audio is valid.
279 | [2.3.6] | Yes. | Yes. | If a recording is created, the name$.duration shadow variable holds the duration (positive integer) of the recording in milliseconds.
281 | [2.3.6] | Yes. | Yes. | The name$.size variable holds the size (positive integer) of the recording in bytes.
282 | [2.3.6] | Yes. | No. | If the dtmfterm attribute is true, and the user terminates the recording by pressing a DTMF key which doesn't match any active DTMF grammar, then the name$.termchar shadow variable is set to the key pressed.
283 | [2.3.6] | Yes. | Yes. | If the dtmfterm attribute is false, and user presses a key which does not match any active DTMF grammar, then recording is not terminated and the name$.termchar shadow variable is undefined when the recording terminates
284 | [2.3.6] | Yes. | Yes. | name$.maxtime shadow variable is true if the recording was terminated because the duration specified by the maxtime attribute was reached.
286 | [2.3.6] | No. | Yes. | If the caller is silent for finalsilence milliseconds during a recording, the recording is terminated.
288 | [2.3.7] | No. | Yes. | A VoiceXML document can initiate a transfer to another entity using the transfer tag, such that the Interpreter remains connected to the original caller and interpretation resumes upon termination of the transfer.
289 | [2.3.7] | No. | No. | A VoiceXML document can initiate a transfer to another entity using the transfer tag, such that the Interpreter disconnects from the caller immediately upon attempting the transfer and continues execution as it would under termination of the Session.
290 | [2.3.7] | No. | No. | A bridged transfer can contain speech grammars such that the interpreter listens to the original caller for the duration of the transfer, terminating the transfer as soon as a spoken utterance matches an active speech grammar.
291 | [2.3.7] | No. | No. | During a bridged transfer, any grammars outside the transfer element are not active and cannot be matched.
292 | [2.3.7] | No. | Yes. | A transfer element that specifies both a 'dest' and 'destexpr' attribute results in an 'error.badfetch' upon loading of the document containing it.
293 | [2.3.7] | No. | Yes. | A transfer element specifying a 'cond' attribute that evaluates to false upon selection of the element by the FIA is not executed.
294 | [2.3.7] | No. | No. | A transfer element not specifying a 'bridge' attribute is executed as a blind transfer.
295 | [2.3.7] | No. | Yes. | A bridged transfer specifying a 'connecttimeout' attribute with a W3C time specification will terminate a transfer attempt if the destination entity cannot be connected to within that period of time.
296 | [2.3.7] | No. | Yes. | A bridged transfer specifying a 'maxtime' attribute with a W3C time specification will terminate a transfer after that period of time has elapsed after connecting to the destination entity if it has not already been terminated for other reasons.
297 | [2.3.7] | No. | No. | A bridged transfer specifying a 'transferaudio' attribute with valid URI to an audio file wil play that audio from the beginning of the transfer attempt until the attempt is terminated or the destination entity is connected to.
298 | [2.3.7] | No. | No. | Upon a successful blind transfer, a 'connection.disconnect.transfer' event is thrown and the transfer name variable remains undefined.
300 | [2.3.7] | No. | No. | If the originating caller hangs up during a bridged transfer, a 'connection.disconnect.hangup' event is thrown and the transfer name variable remains undefined.
301 | [2.3.7] | No. | No. | If the Interpreter is unable to connect to the destination entity when attempting a transfer because it is busy, the transfer name variable is filled with the value 'busy'.
302 | [2.3.7] | No. | No. | If the Interpreter is unable to connect to the destination entity when attempting a transfer because network is busy, the transfer name variable is filled with the value 'network_busy'.
304 | [2.3.7] | No. | No. | If a transfer is terminated because the original caller matches an active DTMF grammar, the transfer name variable is filled with the value 'near_end_disconnect'.
305 | [2.3.7.2.2] | No. | No. | If a transfer is terminated because the destination entity disconnects, the transfer name variable is filled with the value 'far_end_disconnect'.
306 | [2.3.7.2.2] | No. | No. | If a transfer is terminated by the network between the interpreter and the destination entity, the transfer name variable is filled with the value 'network_disconnect'.
307 | [2.3.7.2.2] | No. | Yes. | If a bridge transfer is terminated by the Interpreter because the 'maxtime' has expired without the transfer being terminated, the transfer name variable is filled with the value 'maxtime_disconnect'.
308 | [2.3.7] | No. | Yes. | Upon termination of bridge transfer, the shadow variable 'name$.duration' (where name is the name attribute of the transfer element) is set to the number of seconds from the time the destination entity was connected to and the transfer was terminated.
309 | [2.3.7.2] | No. | No. | Upon termination of bridge transfer due to the caller matching an active speech grammar ('near_end_disconnect'), the 'name$.inputmode' shadow variable is set to 'voice'.
310 | [2.3.7] | No. | No. | Upon termination of bridge transfer due to the caller matching an active DTMF grammar ('near_end_disconnect'), the 'name$.inputmode' shadow variable is set to 'dtmf'.
311 | [2.3.7] | No. | No. | Upon termination of a bridge transfer due to the caller matching an active speech grammar ('near_end_disconnect'), the 'name$.utterance' shadow variable is set to utterance text.
1062 | [2.1] | Yes. | Yes. | A form may contain form-level <grammar> elements.
1043 | [2.3] | Yes. | No. | The input item 'subdialog' may contain the property element. Property elements specify properties that are in effect for this input item.
1044 | [2.3] | No. | No. | The input item 'object' may contain the property element. Property elements specify properties that are in effect for this input item
1045 | [2.3] | Yes. | No. | The input item record may contain the property element. Property elements specify properties that are in effect for this input item.
1046 | [2.3] | No. | No. | The input item 'transfer' may contain the property element. Property elements specify properties that are in effect for this input item.
1047 | [2.3] | Yes. | Yes. | The input item 'field' may contain the prompt element. Prompt elements specify prompts to play when visiting this input item.
1048 | [2.3] | Yes. | Yes. | The input item 'subdialog' may contain the prompt element. Prompt elements specify prompts to play when visiting this input item.
1049 | [2.3] | No. | No. | The input item 'object' may contain the prompt element. Prompt elements specify prompts to play when visiting this input item.
1050 | [2.3] | Yes. | No. | The input item 'record' may contain the prompt element. Prompt elements specify prompts to play when visiting this input item.
1051 | [2.3] | No. | No. | The input item 'transfer' may contain the prompt element. Prompt elements specify prompts to play when visiting this input item.
1053 | [2.3] | No. | Yes. | The input item 'record' may contain the grammar element. Grammar elements specify allowable spoken and character input for this input item.
1054 | [2.3] | No. | No. | The input item 'transfer' may contain the grammar element. Grammar elements specify allowable spoken and character input for this input item.
1055 | [2.3] | Yes. | Yes. | The input item 'field' may contain the catch element, which is in effect for this input item.
1056 | [2.3] | Yes. | Yes. | The input item subdialog may contain the catch element, which is in effect for this input item.
1057 | [2.3] | No. | Yes. | The input item 'object' may contain the catch element, which is in effect for this input item.
1058 | [2.3] | No. | Yes. | The input item 'transfer' may contain the catch element, which is in effect for this input item.
1059 | [2.3] | Yes. | Yes. | The input item 'record' may contain the catch element, which is in effect for this input item.
1060 | [2.3] | Yes. | No. | An 'initial' element may contain property elements.
1061 | [2.3] | Yes. | Yes. | An 'initial' element may contain catch elements.
332 | [3.1.1] | Yes. | Yes. | During a dialog, the interpreter can receive input from the user via the user's spoken utterance, such that the spoken utterance is one of those described by an active grammar.
333 | [3.1.1] | Yes. | Yes. | A grammar can be specified in the format of the XML Form of the W3C Speech Recognition Grammar Specification (SRGS).
334 | [3.1.1] | No. | Yes. | A grammar can be specified in the format of the Augmented BNF (ABNF) Form of the W3C Speech Recognition Grammar Specification.
336 | [3.1.1.1] | Yes. | Yes. | A grammar element can contain child XML elements, such that those elements taken in context of the enclosing grammar element comprise a proper SRGS grammar.
337 | [3.1.1.2] | Yes. | Yes. | A grammar element can specify a 'src' attribute specifying a URI which returns the data of a grammar.
338 | [3.1.1.2] | Yes. | Yes. | A document containing a grammar element specifying both a 'src' attribute and an inline grammar description causes the Interpreter to throw an 'error.badfetch' event upon fetching of the document.
344 | [3.1.2] | Yes. | Yes. | During a dialog, the Interpreter can receive input from the user via a set of dual tone multi frequency (DTMF) key presses, such that the sequence of presses is one of those described by an active grammar.
345 | [3.1.2] | Yes. | Yes. | A DTMF grammar can be specified using the XML form of the SRGS grammar format, as described in the SRGS specification.
346 | [3.1.2] | Yes. | Yes. | A "xml:lang" attribute can be specified on a DTMF grammar, but has no effect upon the grammar handling.
348 | [3.1.3] | Yes. | Yes. | A grammar element specifying a "scope" attribute as a child of a field item throws an "error.badfetch" upon parsing. [This tests scope="dialog".]
357 | [3.1.3] | Yes. | Yes. | A grammar element specifying a "scope" attribute as a child of a link element throws an "error.badfetch" upon parsing.
359 | [3.1.3] | Yes. | Yes. | A grammar element specifying a "scope" attribute as a child of a menu element throws an "error.badfetch" upon parsing.
361 | [3.1.6] | Yes. | Yes. | If a grammar matches but does not return a semantic interpretation, the raw text string for the utterance will be used.
362 | [3.1.6.1] | Yes. | Yes. | If a form-level grammar matches and returns a semantic interpretation for a field name or slot that is a non-scalar ECMAScript variable, the field will be filled with that non-scalar ECMAScript value. The selected property may be a compound object.
363 | [3.1.6.1] | Yes. | Yes. | The slot attribute of the field element can be used to select a sub-property of the result.
364 | [3.1.6.1] | Yes. | Yes. | A specific slot value can fill more than one field if the slot names of the fields are the same.
365 | [3.1.6.2] | Yes. | Yes. | If the result from a field-level grammar is a simple result, it is assigned to the input item variable.
366 | [3.1.6.2] | Yes. | Yes. | If the result from a field-level grammar is a structure and the slot name matches a property, this property is assigned to the input item variable.
367 | [3.1.6.2] | Yes. | Yes. | If the result from a field-level grammar is neither a simple result nor a structure with a property that matches the slot name, the entire semantic result is assigned to the input item variable.
369 | [4.1.3] | Yes. | No. | The interpreter fetches and plays the URI associated with the src attribute of the audio element.
370 | [4.1.3] | Yes. | Yes. | If src and expr are specified on an audio element, error.badfetch is thrown.
371 | [4.1.3] | Yes. | No. | The interpreter evaluates, fetches, and plays the URI associated with the expr attribute of the audio element.
372 | [4.1.3] | Yes. | Yes. | If expr is set to ECMAScript undefined the audio element is ignored.
373 | [4.1.3] | Yes. | Yes. | If the URI associated with src is unavailable, the interpreter renders the content contained by the audio element.
374 | [4.1.3] | Yes. | Yes. | If the URI associated with expr is unavailable, the interpreter renders the content contained by the audio element.
375 | [4.1.3] | Yes. | Yes. | If the URI associated with src is unavailable, and the audio element doesn't contain content, no error is thrown.
376 | [4.1.3] | Yes. | Yes. | If the URI associated with expr is unavailable, and the audio element doesn't contain content, no error is thrown.
377 | [4.1.4] | Yes. | Yes. | If the expr attribute specifies a valid ECMAScript expression, the value element evaluates it correctly.
378 | [4.1.4] | Yes. | Yes. | If the expr attribute specifies an invalid ECMAScript expression, error.semantic is thrown.
379 | [4.1.5] | No. | No. | When set to false, the bargein attribute on the prompt the user should be unable to interrupt the playback of the contents of the prompt.
380 | [4.1.5] | No. | No. | If bargein occurs during any prompt in a sequence, all subsequent prompts are not played. This is required when barge-in is supported by a platform.
381 | [4.1.5] | Yes. | Yes. | When the bargein attribute is set to false on a prompt, any DTMF input buffered in a transition state is deleted from the buffer
382 | [4.1.5] | No. | No. | If the bargein attribute is not specified, then the value of the bargein property is used if set.
387 | [4.1.5] | No. | Yes. | A nomatch event will never be generated in the case of hotword barge-in.
388 | [4.1.7] | Yes. | Yes. | If the interval specified by the timeout attribute of the prompt element is exceeded, the platform will throw a noinput event. The default is the value specified by the timeout property
389 | [4.1.7] | Yes. | Yes. | If several prompts are queued before a field input, the timeout of the last prompt is used.
390 | [5.1] | Yes. | Yes. | VoiceXML variables and ECMAScript variables are contained in the same variable space.
391 | [5.1] | Yes. | Yes. | VoiceXML variables can be used in a script. Variables defined in a script can be used in VoiceXML.
392 | [5.1] | Yes. | Yes. | script can appear everywhere that var can appear.
393 | [5.1] | Yes. | Yes. | Variable names that violate ECMAScript rules cause an error.semantic event to be thrown.
394 | [5.1.1] | Yes. | Yes. | Variables declared without an explicit initial value are initialized to ECMAScript undefined.
395 | [5.1.1] | Yes. | Yes. | Variables must be declared prior to use. Assigning to an undeclared variable does not automatically create it. Instead, it results in error.semantic being thrown.
396 | [5.1.1] | Yes. | Yes. | In a form, variables declared by var and by form items are initialized every time the form is entered. These initializations take place in document order.
397 | [5.1.2] | Yes. | Yes. | Variables can be declared in application, document, dialog and anonymous scopes. Variables declared at one scope are visible at that scope and all more local scopes.
398 | [5.1.2] | Yes. | Yes. | Variables in session scope can be read but not written by VoiceXML documents.
399 | [5.1.2] | Yes. | Yes. | var and script elements that are children of the application root document's vxml element create their variables at application scope. They are no longer accessible when another application is entered.
400 | [5.1.2] | Yes. | Yes. | var and script elements that are children of the document's vxml element create their variables at document scope. They are no longer accessible when another document is entered.
401 | [5.1.2] | Yes. | Yes. | var and script elements that are children of a form element (but not in an anonymous scope) create their variables at dialog scope. They are no longer accessible when another dialog is entered.
402 | [5.1.2] | Yes. | Yes. | var and script elements that are children of block, filled and catch elements (including synonyms for catch, such as nomatch) create their variables at anonymous scope.
403 | [5.1.2] | Yes. | Yes. | Each block, filled and catch element has its own new and separate anonymous scope. The scope is no longer accessible once the element is exited.
404 | [5.1.2] | Yes. | Yes. | Scopes are not cleared when they become inaccessible. Instead, the old scope object is left to exist (or to be garbage collected) and a new one is created and linked into the scope hierarchy. References to previously-existing scope objects will continue to access the old scope objects.
405 | [5.1.2] | Yes. | Yes. | Each scope contains a predefined variable whose name is the same as the scope that refers to the scope itself.
406 | [5.1.2] | Yes. | Yes. | "session", "application", "document", and "dialog" are not reserved words.
407 | [5.1.2] | Yes. | Yes. | When executing in a document that does not have a separate application root document, the application and document scopes are the same; that is, a single scope has variables named both "application" and "document" that are references to the scope itself. This includes execution in an application root document's var and script elements.
408 | [5.1.3] | Yes. | Yes. | Variable references match the closest enclosing scope.
409 | [5.1.4] | Yes. | Yes. | session.connection.local.uri returns a URI which addresses the local interpreter context device.
410 | [5.1.4] | Yes. | Yes. | session.connection.remote.uri returns a URI which addresses the remote caller device.
411 | [5.1.4] | Yes. | Yes. | session.connection.protocol.name returns the name of the connection protocol.
412 | [5.1.4] | Yes. | Yes. | session.connection.protocol.version returns the version of the connection protocol.
413 | [5.1.4] | Yes. | No. | session.connection.redirect returns an array representing the connection redirection paths. The first element is the original called number, the last element is the last redirected number. Each element of the array contains a uri, pi (presentation information), si (screening information), and reason property. The reason property can be either "unknown", "user busy", "no reply", "deflection during alerting", "deflection immediate response", "mobile subscriber not reachable".
414 | [5.1.4] | No. | No. | session.connection.aai returns an application-to-application information passed during connection setup.
415 | [5.1.4] | Yes. | No. | session.connection.originator returns the local or remote property. (For instance, the following ECMAScript would return true if the remote party initiated the connection: var caller_initiate = connection.originator == connection.remote;
416 | [5.1.5] | Yes. | Yes. | application.lastresult$ contains an array of elements, or ECMAScript undefined.
418 | [5.1.5] | Yes. | Yes. | Each element of application.lastresult$ contains "confidence", "utterance", "inputmode" and "interpretation" properties.
419 | [5.1.5] | Yes. | Yes. | The "confidence" property of an element of application.lastresult$ will be a number, not less than 0.0 and not greater than 1.0.
420 | [5.1.5] | Yes. | Yes. | The "utterance" property of an element of application.lastresult$ will be a string.
421 | [5.1.5] | Yes. | Yes. | The "inputmode" property of an element of application.lastresult$ will be either "dtmf" or "voice".
422 | [5.1.5] | Yes. | Yes. | The "interpretation" property of an element of application.lastresult$ will contain the interpretation as described in section 3.1.5.
423 | [5.1.5] | Yes. | Yes. | The elements of application.lastresult$ will be sorted from highest confidence score to lowest, with ties resolved by sorting by the precedence relationship among the grammars producing the interpretations.
424 | [5.1.5] | Yes. | Yes. | Different elements in application.lastresult$ will always differ in their utterance, interpretation, or both.
425 | [5.1.5] | Yes. | Yes. | The number of elements in application.lastresult$ is never more than the value of the property "maxnbest", and never less than one, unless the value of application.lastresult$ itself is undefined.
426 | [5.1.5] | Yes. | Yes. | If the value of application.lastresult$ is not undefined, application.lastresult$ itself will contain the properties confidence, utterance, inputmode and intepretation corresponding to those of application.lastresult$[0].
428 | [5.1.5] | Yes. | Yes. | application.lastresult$ is not changed after a noinput.
430 | [5.2] | Yes. | Yes. | Catch elements are inherited as if by copy. This affects scope resolution, further thrown events, and relative URL references.
431 | [5.2.1] | Yes. | Yes. | The interpreter throws the named event.
432 | [5.2.1] | Yes. | Yes. | The interpreter observes event counting when an application-defined event is thrown.
433 | [5.2.1] | Yes. | Yes. | If neither event nor eventexpr are specified then an error.badfetch event is thrown.
434 | [5.2.1] | Yes. | Yes. | If both event and eventexpr are specified then an error.badfetch event is thrown.
435 | [5.2.1] | Yes. | Yes. | If both message and messageexpr are specified then an error.badfetch event is thrown.
436 | [5.2.2] | Yes. | Yes. | A VoiceXML interpreter must execute the content within the selected event handler.
437 | [5.2.2] | Yes. | Yes. | Anonymous scope variables _event and _message are available within the event handler.
438 | [5.2.2] | Yes. | Yes. | Assuming no cond or count attribute specified, given a field level event handler, the interpreter must select it when the corresponding event is thrown.
439 | [5.2.2] | Yes. | Yes. | Assuming no cond or count attribute specified and no field-level event handler, given a form-level event handler, the interpreter must select it when the corresponding event is thrown.
440 | [5.2.2] | Yes. | Yes. | Assuming no cond or count attribute specified and no field- or form-level event handler, given a document-level event handler, the interpreter must select it when the corresponding event is thrown.
441 | [5.2.2] | Yes. | Yes. | Assuming no cond or count attribute specified and no field-, form-, or document-level event handler, given an application-level event handler, the interpreter must select it when the corresponding event is thrown.
442 | [5.2.2] | Yes. | Yes. | If the cond attribute of the most inner-scoped event handler evaluates to false, the interpreter must not select it and instead select the next qualifying event handler.
443 | [5.2.2] | Yes. | Yes. | The cond attribute of an event handler must be evaluated in the context of the scope where the event is thrown.
444 | [5.2.2] | Yes. | Yes. | The interpreter executes the event handler with highest count attribute not greater than the actual event count.
446 | [5.2.2] | Yes. | Yes. | Event count matching takes precedence over scoping, ie on the second occurrence of an event a root document level handler with count=2 takes precedence over a field level handler with count=1
447 | [5.2.2] | Yes. | Yes. | Counters are increased for every catch handler that specifies a matching prefix for an event via the event attribute.
448 | [5.2.2] | Yes. | Yes. | The interpreter maintains a separate count for each event when multiple events specified in the event attribute of the catch element.
449 | [5.2.2] | Yes. | Yes. | If unspecified, the count attribute of the catch element defaults to 1.
450 | [5.2.2] | Yes. | Yes. | The interpreter selects the first handler in document order when two or more event handlers have the same count attribute and scope.
451 | [5.2.2] | Yes. | Yes. | The interpreter executes a handler that speciifies a space-delimited list of events in the event attribute when the corresponding events are thrown.
452 | [5.2.2] | Yes. | Yes. | An event handler catches all events if the event attribute not specified.
453 | [5.2.2] | Yes. | Yes. | An event handler catches all events for which the event attribute specifies a token prefix of the event (NB token prefix matching is done after removing trailing dots.)
454 | [5.2.2] | Yes. | Yes. | An event handler does not catch events for which the event attribute specifies a string prefix of the event which is not a token prefix.
455 | [5.2.3] | Yes. | Yes. | Exactly one of "next", "expr", "event" or "eventexpr" must be specified; otherwise, an error.badfetch event is thrown. Exactly one of "message" or "messageexpr" may be specified; otherwise, an error.badfetch event is thrown.
457 | [5.2.3] | Yes. | Yes. | When event or eventexpr is specified, and the link is matched, the corresponding event is thrown.
458 | [5.2.3] | Yes. | Yes. | When next or expr is specified, and the link is matched, the interpreter navigates to the specified URI.
460 | [5.2.3] | Yes. | Yes. | The noinput element is executed when an noinput event is thrown.
461 | [5.2.3] | Yes. | Yes. | The noinput element obeys the same selection and execution rules as a catch element whose event attribute is set to "noinput".
462 | [5.2.3] | Yes. | Yes. | The noinput element has exactly equal precedence to a catch element that specifies the noinput event, ie the choice between a catch element and a noinput element at the same scope level and count is made on the basis of document order.
464 | [5.2.3] | Yes. | Yes. | The nomatch element is executed when a nomatch event is thrown.
465 | [5.2.3] | Yes. | Yes. | The nomatch element obeys the same selection and execution rules as a catch element whose event attribute is set to "nomatch".
466 | [5.2.3] | Yes. | Yes. | The nomatch element has exactly equal precedence to a catch element that specifies the nomatch event, ie the choice between a catch element and a nomatch element at the same scope level and count is made on the basis of document order.
468 | [5.2.3] | Yes. | Yes. | The error element is executed when an error event is thrown.
469 | [5.2.3] | Yes. | Yes. | The error element is executed when a more specific error event is thrown (e.g. error.badfetch)
470 | [5.2.4] | Yes. | Yes. | The error element is executed when an application-defined event prefixed with "error" is thrown.
471 | [5.2.3] | Yes. | Yes. | The error element has exactly equal precedence to a catch element that specifies the error event, ie the choice between a catch element and an error element at the same scope level and count is made on the basis of document order.
472 | [5.2.3] | Yes. | Yes. | The error element obeys the same selection rules as a catch element whose event attribute is set to "error".
473 | [5.2.3] | Yes. | Yes. | The error element obeys the same execution rules as a catch element whose event attribute is set to "error".
474 | [5.2.3] | Yes. | Yes. | The help element is executed when an help event is thrown.
475 | [5.2.3] | Yes. | Yes. | The help element obeys the same selection and execution rules as a catch element whose event attribute is set to "help".
476 | [5.2.3] | Yes. | Yes. | The help element has exactly equal precedence to a catch element that specifies the help event, ie the choice between a catch element and a help element at the same scope level and count is made on the basis of document order.
478 | [5.2.4] | Yes. | Yes. | An event handler catches all events if the event attribute consists of a single dot (".").
479 | [5.2.4] | Yes. | Yes. | Event handlers which specify more specific event names, eg event.foo.bar have equal precedence with event handlers that specify less specific event names, eg event.foo
480 | [5.2.4] | Yes. | Yes. | Event handlers are executed in the context in which the event was thrown. Check for the existence of variables in the scope in which the event was thrown.
481 | [5.2.4] | Yes. | Yes. | Event handlers are executed in the context in which the event was thrown. Check that URLs (audio/@src, goto/@next, script/@src, etc) are resolved relative to the document in which the event was thrown.
482 | [5.2.5] | Yes. | No. | The interpreter must support a default cancel event handler. No audio is provided, the interpreter does not reprompt and does not exit.
483 | [5.2.5] | Yes. | No. | The interpreter must support a default exit event handler. No audio is provided and the interpreter exits.
484 | [5.2.5] | Yes. | No. | The interpreter must support a default error event handler. The interpreter provides platform-specific audio and exits.
485 | [5.2.5] | Yes. | No. | The interpreter must support a default help event handler. The interpreter provides platform-specific audio and reprompts.
486 | [5.2.5] | Yes. | No. | The interpreter must support a default noinput event handler. No audio is provided and the interpreter reprompts.
487 | [5.2.5] | Yes. | No. | The interpreter must support a default nomatch event handler. The interpreter provides platform-specific audio and reprompts.
488 | [5.2.5] | Yes. | No. | The interpreter must support a default maxspeechtimeout event handler. The interpreter provides platform-specific audio and reprompts.
489 | [5.2.5] | Yes. | No. | The interpreter must support a default connection.disconnect event handler. No audio is provided and the interpreter exits.
490 | [5.2.5] | Yes. | No. | For any other unhandled event, the interpreter provides platform-specific audio and exits
491 | [5.2.6] | No. | Yes. | With universal grammars active, requesting to cancel playing of the current prompt throws the cancel event.
492 | [5.2.6] | No. | Yes. | With universal grammars active, asking to exit throws the exit event.
493 | [5.2.6] | No. | Yes. | With universal grammars active, asking for help throws the help event.
494 | [5.2.6] | Yes. | Yes. | When the user hangs up the connection.disconnect.hangup event is thrown.
495 | [5.2.6] | No. | Yes. | When the user has been transferred unconditionally to another line and will not return the connection.disconnect.transfer event is thrown.
497 | [5.2.6] | Yes. | Yes. | The nomatch event is thrown if the user says something and is not recognized.
498 | [5.2.6] | Yes. | Yes. | The maxspeechtimeout event is thrown if the user's input exceeds the maxspeechtimeout property.
499 | [5.2.6] | Yes. | Yes. | If the interpreter encounters a syntax error while loading a document (eg no vxml element), it throws error.badfetch in the requesting document.
500 | [5.2.6] | Yes. | Yes. | If an invalid URL is specified for a document fetch, the interpreter throws error.badfetch.http.404 in the requesting document.
501 | [5.2.6] | Yes. | Yes. | If a document fetch times out, the interpreter throws error.badfetch in the requesting document.
502 | [5.2.6] | Yes. | Yes. | If a server returns HTTP error code 4xx the event error.badfetch.http.4xx should be thrown in the requesting document.
503 | [5.2.6] | Yes. | Yes. | If a server returns HTTP error code 5xx the event error.badfetch.http.5xx should be thrown in the requesting document
505 | [5.2.6] | Yes. | Yes. | If an unsupported language is specified for speech recognition, the interpreter throws error.unsupported.language.
506 | [5.2.6] | Yes. | Yes. | If an unsupported language is specified for speech synthesis, the interpreter throws error.unsupported.language.
508 | [5.2.6] | Yes. | Yes. | If an unsupported grammar format is specified, the interpreter throws error.unsupported.format.
322 | [2.5] | Yes. | Yes. | If an application root document has a document-level link, its grammars are active no matter what document of the application is being executed.
510 | [5.3.1] | Yes. | Yes. | A variable declared at document scope is accessible within an anonymous scope contained within the same document.
511 | [5.3.1] | Yes. | Yes. | Declaring a variable at an anonymous scope, the variable is not accessible within another anonymous scope.
512 | [5.3.1] | Yes. | Yes. | A variable declared at a higher scope (e.g. document) is shadowed by a variable at a lower scope (e.g. anonymous).
513 | [5.3.1] | Yes. | Yes. | When declaring the same variable multiple times with different initial values in the same scope, declarations will apply in document order.
514 | [5.3.2] | Yes. | Yes. | When expr is set to a valid expression in an assign, the named variable is set correctly.
515 | [5.3.2] | Yes. | Yes. | If name is set to an undefined variable in an assign, error.semantic is thrown.
516 | [5.3.2] | Yes. | Yes. | If expr contains an undefined variable in an assign, error.semantic is thrown.
517 | [5.3.2] | Yes. | Yes. | If expr contains a semantic error (e.g.it contains a non-existent function named x), an error.semantic is thrown.
518 | [5.3.3] | Yes. | Yes. | When the namelist attribute of the clear element specifies a specific set of one or more form item variables, only those form items are cleared.
519 | [5.3.3] | Yes. | Yes. | When the namelist attribute of the clear element is omitted, all form items in the current form are cleared.
520 | [5.3.3] | Yes. | Yes. | If variables that are not form item variables are specified in the "namelist" attribute of the clear element, those variables are set to ECMAScript undefined.
521 | [5.3.4] | Yes. | Yes. | if parent cond of if element evaluates to false, the interpreter executes the content following the else element up to the closing if tag.
522 | [5.3.4] | Yes. | Yes. | if parent cond of if element evaluates to true, the interpreter does not execute the content following the else element up to the closing if tag.
523 | [5.3.5] | Yes. | No. | If a prompt element appears in executable content, the "count" attribute is ignored, but the "cond" element is respected.
524 | [5.3.5] | Yes. | Yes. | Wherever prompt is allowed, PCDATA is treated as if it had been wrapped in prompt /prompt.
525 | [5.3.6] | Yes. | No. | Execution of a reprompt element causes the FIA to perform normal selection and queueing of prompts after execution of a catch element.
526 | [5.3.7] | Yes. | Yes. | Setting next to a fully-qualified URL (excluding fragment identifier) that points to an existing VoiceXML document causes the INTERPRETER to transition to that document and begin execution of the first form.
527 | [5.3.7] | Yes. | Yes. | Setting next to a relative URL (excluding fragment identifier) that points to an existing VoiceXML document causes the INTERPRETER to transition to that document and begin execution of the first form.
528 | [5.3.7] | Yes. | Yes. | Setting next to a fully-qualified URL including fragment identifier that points to an existing VoiceXML document and form causes the INTERPRETER to transition to the document and begin execution of the specified form.
529 | [5.3.7] | Yes. | Yes. | Setting next to a relative URL including fragment identifier that points to an existing VoiceXML document and form causes the INTERPRETER to transition to that document and begin execution of the specified form.
530 | [5.3.7] | Yes. | Yes. | Setting expr to an ECMAScript expression that evaluates to a fully-qualified URL (excluding fragment identifier) that points to an existing VoiceXML document causes the INTERPRETER to transition to that document and begin execution of the first form.
531 | [5.3.7] | Yes. | Yes. | Setting next to a URL that points to a non-existent VoiceXML document causes the interpreter to throw a catchable error.badfetch event.
532 | [5.3.7] | Yes. | Yes. | Setting expr to a URL that points to a non-existent VoiceXML document causes the INTERPRETER to thrown a catchable error.badfetch event.
533 | [5.3.7] | Yes. | Yes. | Setting next to a fragment identifier that identifies an existing form in the current document causes the INTERPRETER to transition to that form with the state of the current document and application in tact.
534 | [5.3.7] | Yes. | Yes. | Setting next to a non-fragment URL of the current document causes the INTERPRETER to transition to the first form of the current document and reset the state of the document including any variables.
535 | [5.3.8] | Yes. | Yes. | The URI referenced by submit's next or expr attribute is always fetched, even if it is just a fragment.
536 | [5.3.8] | Yes. | Yes. | If submit has a namelist attribute, all and only those variables are submitted.
537 | [5.3.8] | Yes. | Yes. | If submit has no namelist attribute, all and only the named input items in the current form are submitted.
538 | [5.3.8] | Yes. | Yes. | Both declared VoiceXML variables and declared ECMAScript variables can be submitted. This includes properties of ECMAScript objects.
539 | [5.3.8] | Yes. | Yes. | Interpreters must support GET and POST as submit methods. GET must be the default.
541 | [5.3.8] | Yes. | Yes. | When an ECMAScript variable is submitted, its value is first converted to a string.
542 | [5.3.8] | Yes. | Yes. | Specifying a URL that points to a non-existent resources causes the INTERPRETER to throw a catchable error.badfetch event.
543 | [5.3.8] | Yes. | Yes. | Exactly one of "next" or "expr" must be specified; otherwise, an error.badfetch event is thrown.
544 | [5.3.9] | Yes. | No. | Executing exit must terminate all loaded documents and return control to the interpreter context.
545 | [5.3.9] | Yes. | No. | If both "expr" and "namelist" attributes of exit are specified, an error.badfetch event is thrown.
546 | [5.3.10] | Yes. | Yes. | When return is executed while not inside a subdialog context, an error.semantic event is thrown.
547 | [5.3.10] | Yes. | Yes. | Exactly one of "event", "eventexpr" or "namelist" may be specified; otherwise, an error.badfetch event is thrown.
549 | [5.3.10] | Yes. | Yes. | The interpreter throws throws error.semantic if a return element is encountered when not executing in the context of a subdialog.
550 | [5.3.10] | Yes. | Yes. | If the namelist attribute is specified, the specified variables become properties of an ECMAScript object accessible via the name attribute of the calling subdialog element.
551 | [5.3.10] | Yes. | Yes. | If the event or eventexpr attribute is specified, the named event is thrown at the invocation point.
552 | [5.3.11] | Yes. | No. | When the interpreter executes a disconnect element, it must drop the call.
553 | [5.3.11] | Yes. | Yes. | When the interpreter executes a disconnect element, it must throw a catchable connection.disconnect.hangup event.
554 | [5.3.11] | Yes. | Yes. | When the caller hangs up, the interpreter must throw a catchable connection.disconnect.hangup event.
555 | [5.3.13] | Yes. | Yes. | ECMAScript expressions within the PCDATA in log must be evaluated in document order.
556 | [5.3.12] | Yes. | Yes. | A script element is executed in the scope of its containing element.
557 | [5.3.12] | Yes. | Yes. | When a script element declared in a block element contains a function, an attempt to call that function from another block causes the INTERPRETER to throw an error (error.semantic?)
558 | [5.3.12] | Yes. | Yes. | A variable declared using the var element is accessible to a script declared at equal more local scope.
559 | [5.3.12] | Yes. | Yes. | A variable declared within an inline or externally referenced script block is accessible from a var or assign element declared at equal or more local scope.
560 | [5.3.12] | Yes. | Yes. | When the script element specifies a src attribute that references a URL that references a non-existent resource, the interpreter throws error.badfetch.
561 | [5.3.12] | Yes. | Yes. | Either an "src" attribute or an inline script (but not both) must be specified; otherwise, an error.badfetch event is thrown.
562 | [5.3.13] | Yes. | Yes. | The use of the log element has no side-effects on interpretation.
563 | [6.1.1] | Yes. | Yes. | The interpreter context is always required to honor the safe fetchhint.
564 | [6.1.1] | Yes. | Yes. | When transitioning from one dialog to another if the referenced URI names a document (e.g. "doc.vxml#dialog"), or if query data is provided (through POST or GET), then the new document goes through its initialization phase . Applies to subdialog, goto, submit, link, or choice element.
565 | [6.1.1] | Yes. | Yes. | If a URI reference in a goto transition contains only a fragment (e.g., "#my_dialog"), then no document is fetched, and no initialization of that document is performed.
566 | [6.1.1] | Yes. | Yes. | If a URI reference in a submit transition is accompanied by a query string or by a namelist attribute there will a fetch and the new document is initialized.
567 | [6.1.1] | Yes. | Yes. | If the URI reference to the root document contains a query string or a namelist attribute, the root document is fetched.
568 | [6.1.1] | Yes. | No. | If specified, fetchaudio plays during a long fetch.
569 | [6.1.1] | Yes. | No. | If fetchaudio is not specified, but a non-empty fetchaudio property exists, fetchaudio plays during a long fetch.
570 | [6.1.1] | Yes. | No. | If not specified, and the fetchaudio property is not set, fetchaudio does not play during a long fetch.
571 | [6.1.1] | Yes. | Yes. | If an error occurs retrieving fetchaudio from its URI, no badfetch event is thrown and no audio is played during the fetch.
572 | [6.1.1] | Yes. | Yes. | If content is not returned within the specified fetchtimeout, an error.badfetch event is thrown.
573 | [6.1.1] | Yes. | Yes. | If content is returned within the specified fetchtimeout, document processing proceeds as normal.
574 | [6.1.2] | Yes. | Yes. | If maxage is specified and the resource age is greater than the maxage, the interpreter must revalidate against the server
576 | [6.1.2] | Yes. | Yes. | If maxstale attribute is specified and the resource age has exceeded its expiration time by more than the maxstale time, the interpreter must revalidate against the server.
577 | [6.1.2] | Yes. | Yes. | Setting maxage of zero forces the interpreter to do revalidate the resource against the server.
579 | [6.1.3] | Yes. | Yes. | When an interpreter context does prefetch a resource, it must ensure that the resource fetched is precisely the one needed.
580 | [6.1.3] | Yes. | Yes. | If the interpreter prefetches a resource, and the URI is computed with an expr attribute, the interpreter context must not move the fetch up before any assignments to the expression's variables.
585 | [6.2.1] | Yes. | Yes. | The interpreter must successfully parse and execute a VoiceXML document containing zero or more meta elements with name and content attributes.
586 | [6.2.1] | Yes. | Yes. | The interpreter must successfully parse and execute a VoiceXML document containing zero or more meta elements with name and http-equiv attributes.
587 | [6.2.1] | Yes. | Yes. | Exactly one of "name" or "http-equiv" must be specified; otherwise, an error.badfetch event is thrown.
588 | [6.2.1] | Yes. | Yes. | If the http-equiv attribute is set to "expires" and the content attribute is set to "0", the interpreter MUST not cache the document.
589 | [6.2.2] | Yes. | Yes. | An interpreter MUST successfully parse and execute a VoiceXML document containing a metadata element containing any valid schema including the recommended general metadata properties defined in the Dublin Core Metadata Initiative.
319 | [2.5] | Yes. | Yes. | When a link specifying next or expr is matched, the interpreter transitions to the document or dialog specified by next or expr.
592 | [6.3.2] | Yes. | Yes. | When the "confidencelevel" property is specified, the interpreter rejects results (throwing a nomatch event) when the confidence level of recognizer is less than that of the property.
595 | [6.3.2] | Yes. | Yes. | When the "speedvsaccuracy" property is specified with value M, the recognizer is at least as fast as when the specified value is N, such that M < N, given the same input and other context.
596 | [6.3.2] | Yes. | Yes. | When the "completetimeout" property is specified, the recognizer will wait the specified number of seconds of silence before determining that the user has finished speaking a matching utterance (or will not speak).
597 | [6.3.2] | Yes. | Yes. | When the "incompletetimeout" property is specified, the recognizer will wait the specified number of seconds of silence before determining that the user has finished speaking and the utterance does not match a grammar.
598 | [6.3.3] | Yes. | Yes. | When the "interdigittimeout" property is specified, and the recognizer has received DTMF input but could possibly match a grammar if more digits were entered, it will wait the specified number of seconds before determining that no more digits will be entered.
599 | [6.3.3] | Yes. | Yes. | When the "termtimeout" property is specified, and the recognizer has received DTMF input matching a grammar and the termchar is non-empty, the user can enter an optional termchar DTMF. If the user fails to enter this optional DTMF within termtimeout, the recognition ends and the recognized value is returned.
601 | [6.3.4] | Yes. | No. | The value of the bargein property controls whether barge-in is allowed by default for prompts.
603 | [6.3.4] | Yes. | Yes. | The value of the timeout property controls the default time after which a noinput event is thrown by the platform.
604 | [6.3.5] | Yes. | Yes. | If any of the various *fetchhint properties is set to "safe", content of that time is never fetched until it is needed.
605 | [6.3.5] | Yes. | Yes. | A cached resource of a certain type must be reloaded if the *maxage property for its type is less than its current age.
606 | [6.3.5] | Yes. | Yes. | A cached resource of a certain type must be reloaded if the *maxstale property for its type is less than its current staleness.
607 | [6.3.5] | Yes. | No. | Fetchaudio will not begin playing until the amount of time specified in the fetchaudiodelay property has elapsed.
608 | [6.3.5] | Yes. | Yes. | Fetchaudio, once it begins playing, will not be interrupted until at least the amount of time specified in the fetchaudiominimum property.
1064 | [2.1] | Yes. | Yes. | A form may contain <property> elements.
1065 | [2.1] | Yes. | Yes. | A form may contain <script> elements.
1025 | [2.3] | Yes. | Yes. | The form item initial has a result variable, specified by the name attribute. This variable may be given an initial value with the expr attribute.
614 | [2.3.2] | Yes. | Yes. | When the block cond attribute evaluates to false, the interpreter does not execute the element or its contents.
620 | [5.3.8] | Yes. | Yes. | Variables associated with the namelist should be URI escaped.
621 | [2.3.4] | Yes. | Yes. | When the element's cond attribute evaluates to false, the interpreter does not execute the element or its contents.
613 | [6.5] | Yes. | Yes. | Time designations follow those used in W3C's Cascading Style Sheet recommendation. The valid time unit identifiers are ms (milliseconds, the default) and s (seconds).
624 | [2.3.7] | No. | No. | A bridged transfer can contain DTMF grammars such that the interpreter listens to the original caller for the duration of the transfer, terminating the transfer as soon as DTMF input matches an active DTMF grammar.
626 | [1.2.5] | Yes. | Yes. | An implementation platform must support text-to-speech
627 | [1.2.5] | Yes. | No. | Audio files are referred to by URI
628 | [1.2.5] | Yes. | Yes. | The implementation must report characters (DTMF entered by the user)
629 | [1.2.5] | No. | No. | If an audio input resource is not available, an error.noresource event must be thrown
630 | [1.2.5] | No. | Yes. | The interpreter MAY support other formats such as the JSpeech Grammar Format [JSGF] or proprietary formats.
632 | [1.3.1] | Yes. | Yes. | Each field may specify a grammar that defines the allowable inputs for that field.
633 | [1.3.5] | Yes. | Yes. | Handling Platform generated events
634 | [1.3.5] | Yes. | Yes. | Handling Interpreter generated events
640 | [1.5.1] | Yes. | Yes. | vxml- xml:lang can be omitted and a platform specific default shall be used
649 | [1.5.2] | Yes. | Yes. | Transition to doc with application attr same (with query string)
650 | [1.5.2] | Yes. | Yes. | Transition to doc with application attr same (with fragment)
654 | [1.5.3] | Yes. | Yes. | Subdialog results are accessed through properties of the variable defined by the name attribute of the subdialog element.
655 | [1.5.3] | Yes. | Yes. | If subdialog execution is transferred to another subdialog using goto, when the second dialog returns, control is returned directly to the dialog.
656 | [1.5.3] | Yes. | Yes. | If subdialog execution calls a second subdialog execution, when the second dialog returns, control is returned directly to the calling subdialog dialog.
657 | [1.5.4] | Yes. | Yes. | A VoiceXML interpreter execution in final processing state must exit if a prompt element is encountered during execution.
1001 | [5.3.7] | Yes. | Yes. | Exactly one of "next", "expr", "nextitem" or "expritem" must be specified; otherwise, an error.badfetch event is thrown
1002 | [5.3.7] | Yes. | Yes. | Setting expr to an ECMAScript expression that evaluates to a relative URL (excluding fragment identifier) that points to an existing VoiceXML document causes the INTERPRETER to transition to that document and begin execution of the first form.
1003 | [5.3.7] | Yes. | Yes. | Setting expr to an ECMAScript expression that evaluates to a fully-qualified URL including fragment identifier that points to an existing VoiceXML document causes the INTERPRETER to transition to that document and begin execution of the specified form.
1004 | [5.3.7] | Yes. | Yes. | Setting expr to an ECMAScript expression that evaluates to a relative URL including fragment identifier that points to an existing VoiceXML document causes the INTERPRETER to transition to that document and begin execution of the specified form.
1005 | [5.3.7] | Yes. | Yes. | Setting nextitem to an existent form item of the current form causes the INTERPRETER to transition to that specified form item and continue execution.
1006 | [5.3.7] | Yes. | Yes. | Setting expritem to an ECMAScript expression that evaluates to an existent form item of the current form causes the INTERPRETER to transition to that specified form item and continue execution.
1007 | [5.3.7] | Yes. | Yes. | Setting nextitem to a non-existent form item (in the current form) causes the INTERPRETER to thrown a catchable error.badfetch event
1008 | [5.3.7] | Yes. | Yes. | Setting expritem to an ECMAScript expression that evaluates to a non-existent form item (in the current form) causes the interpreter to throw a catchable error.badfetch event.
1010 | [2.3.6] | Yes. | No. | If the modal attribute is set to false, and DTMF input matches an active non-local grammar, then the recording is terminated, the record variable is undefined and control is transfered to the element containing the matched grammar.
1011 | [2.3.6] | Yes. | No. | If the modal attribute is set to true, DTMF input cannot match any non-local grammars.
1012 | [2.3.6] | Yes. | Yes. | If the expr attribute evaluates to a defined value, then the record element is not visited.
1013 | [2.3.6] | Yes. | Yes. | If the cond attribute is specified and evaluates after conversion to boolean to true, then the record element is visited.
1014 | [2.3.6] | Yes. | Yes. | If the cond attribute is specified and evaluates after conversion to boolean to false, then the record element is not visited.
1015 | [2.3.6] | Yes. | Yes. | If no audio input is received from the user before the timeout period expires, then record variable is not defined, and a timeout event is thrown.
1016 | [2.3.6] | Yes. | Yes. | Recording is terminated when user hangs up and a disconnect event is thrown. If audio has been collected, then the audio recorded up until hangup is available through the record variable.
1017 | [2.3.6] | Yes. | Yes. | The value of the record variable 'name' is also available as dialog.'name'.
1018 | [2.3.6] | Yes. | No. | If the beep attribute is set to true, then a tone is emitted prior to recording.
1019 | [2.3.6] | Yes. | Yes. | If DTMF input is received before the end of playback of record prompts, or the end of the timeout period, then no audio is collected, the record variable remains undefined and an noinput event thrown.
1020 | [2.3.6] | No. | Yes. | If recording is taking place, and speech input matches a local speech grammar, then the recording variable is defined, the utterance shadow variable is set to the string of words spoken, and the confidence shadow variable is set to the recognition confidence level.
1021 | [2.3.6] | No. | Yes. | Speech input not matching any active speech grammar is ignored (and therefore does not terminate or otherwise affect recording).
1022 | [5.1.2] | Yes. | Yes. | New session variables cannot be declared by VoiceXML documents.
1063 | [2.1] | Yes. | Yes. | A form may contain <link> elements.
1026 | [2.3] | Yes. | Yes. | The form item subdialog has a result variable, specified by the name attribute. This variable may be given an initial value with the expr attribute.
1027 | [2.3] | No. | Yes. | The form item object has a result variable, specified by the name attribute. This variable may be given an initial value with the expr attribute.
1029 | [2.3] | No. | Yes. | The form item transfer has a result variable, specified by the name attribute. This variable may be given an initial value with the expr attribute.
1032 | [2.3] | Yes. | Yes. | The form item 'initial' has a guard condition specified with the cond attribute. A form item is visited if it is not filled and its cond is not specified or evaluates, after conversion to boolean, to true.
1034 | [2.3] | No. | Yes. | The form item 'object' has a guard condition specified with the cond attribute. A form item is visited if it is not filled and its cond is not specified or evaluates, after conversion to boolean, to true.
1037 | [2.3] | Yes. | Yes. | The input item 'field' may contain the filled element. Filled elements contain an action to execute after the result input item variable is filled in.
1038 | [2.3] | Yes. | Yes. | The input item subdialog may contain the filled element. Filled elements contain an action to execute after the result input item variable is filled in.
1039 | [2.3] | No. | Yes. | The input item object may contain the filled element. Filled elements contain an action to execute after the result input item variable is filled in.
1040 | [2.3] | Yes. | Yes. | The input item record may contain the filled element. Filled elements contain an action to execute after the result input item variable is filled in.
1041 | [2.3] | No. | Yes. | The input item transfer may contain the filled element. Filled elements contain an action to execute after the result input item variable is filled in.
1042 | [2.3] | Yes. | Yes. | The input item 'field' may contain the property element. Property elements specify properties that are in effect for this input item.
312 | [2.4] | Yes. | Yes. | When <filled> is a child of a <form>, and the mode attribute is set to "any", the filled is executed when any of the form items specified in the namelist has been filled.
313 | [2.4] | Yes. | Yes. | When <filled> is a child of a <form>, and the mode attribute is set to "all", the filled is executed when all of the form items specified in the namelist have been filled.
314 | [2.4] | Yes. | Yes. | A <filled> element within an input item cannot specify a mode.
315 | [2.4] | Yes. | Yes. | A <filled> element within an input item cannot specify a namelist.
316 | [2.4] | Yes. | Yes. | Control items may not be specified in the namelist of the <filled> element.
317 | [2.5] | Yes. | Yes. | A link element may have one or more grammars that are scoped to the element containing the link.
320 | [2.5] | Yes. | Yes. | A link can be a child of vxml, form, or of the form items field and initial.
321 | [2.5] | Yes. | Yes. | A link at the form level has grammars active while the user is in that form.
323 | [2.5] | Yes. | Yes. | A link at the vxml level has grammars that are active throughout the document.
324 | [2.5] | Yes. | Yes. | If execution is in a modal form item, then link grammars at the form or document level are not active. [Not application?]
325 | [2.5] | Yes. | Yes. | When a link that specifies event or eventexpr is matched, the specified event is thrown.
326 | [2.5] | Yes. | Yes. | Events thrown as a result of matching a link are thrown at the current location in the execution, not at the location where the link is specified.
327 | [2.5] | Yes. | Yes. | When a link is matched, application.lastresult$ is assigned.
328 | [2.5] | Yes. | Yes. | A link may specify a message or messageexpr attribute providing additional context about the event being thrown. The message is available as the value of the _message variable within the scope of the catch element the interpreter selects to handle the event.
329 | [2.5] | Yes. | Yes. | A link may specify a dtmf attribute that identifies the sequence of DTMF digits that cause the interpreter to activate the link.
330 | [2.5] | Yes. | Yes. | Exactly one of next, expr, event or eventexpr must be specified; otherwise, an error.badfetch event is thrown.
331 | [2.5] | Yes. | Yes. | Exactly one of message or messageexpr may be specified; otherwise, an error.badfetch event is thrown.
623 | [4.1] | Yes. | Yes. | When the prompt element's cond attribute evaluates to false, the interpreter does not execute the element or its contents.
509 | [5.3] | Yes. | Yes. | If an executable element generates an error, the error is thrown immediately. Subsequent executable elements in that block of procedural logic are not executed.
591 | [6.3] | Yes. | Yes. | A property specified at a more local scope (e.g. form) takes precedence over the same property specified at an outer scope (e.g. document).
611 | [6.4] | Yes. | Yes. | Exactly one of "expr" or "value" on param must be specified; otherwise, an error.badfetch event is thrown.
612 | [6.4] | Yes. | Yes. | When param is contained in a subdialog element, the values specified by it are used to initialize dialog var elements in the subdialog that is invoked.
1066 | [2.1.5] | Yes. | Yes. | A form-level grammar cannot fill <block>, <initial> or <var>.
1067 | [2.1.6.1] | Yes. | Yes. | On entering a form, all form item variables and variables declared in a form by <var> are initialised by the expr attribute if defined.
1068 | [2.1.6.1] | Yes. | Yes. | On entering a form, all form item variables and variables declared in a form by <var> are initialised to undefined if no expr attribute is defined.
1069 | [2.1.6.1] | Yes. | Yes. | Form item variables and variables declared in a form by <var> are initialised in document order.
1070 | [2.1.6.1] | Yes. | Yes. | Form level <script> elements are evaluated in document order at the same time as form item variables are initialised.
1071 | [2.1.6.1] | Yes. | Yes. | When a form is entered, the prompt counter is initialised to 1 for every input item. Thus the prompt with count=1 will always be played first for all input items.
1072 | [2.1.6.1] | Yes. | Yes. | When a form is entered, the prompt counter is initialised to 1 for every <initial>. Thus the prompt with count=1 will always be played first for any <initial> item.
1074 | [2.1.6.2.1] | Yes. | Yes. | For every type of form item except <initial>, that item will be selected by the FIA if it is the first eligible form item in document order and the previous loop of the FIA did not end in a goto nextitem
1075 | [2.1.6.2.1] | Yes. | Yes. | For every type of form item, the form item is not eligible to be visited by the FIA if the form item variable is not undefined. This applies even if there is a cond attribute that evaluates to true.
1076 | [2.1.6.2.1] | Yes. | Yes. | For every type of form item, the form item is not eligible to be visited by the FIA if the form item has a cond attribute evaluating to false.
1077 | [2.1.6.2.1] | Yes. | Yes. | For every type of form item, the form item is eligible to be visited by the FIA if the form item has a cond attribute evaluating to true and the form item variable is undefined.
1078 | [2.1.6.2.1] | Yes. | Yes. | For every type of form item, the form item is eligible to be visited by the FIA if the form item has no cond attribute and the form item variable is undefined.
1080 | [2.1.6.2.1] | Yes. | Yes. | For every type of form item, the cond attribute is evaluated in the dialog scope.
1081 | [3.1.4] | Yes. | Yes. | If no grammars are active when an input is expected, the platform must throw an error.semantic event. The error will be thrown in the context of the executing element.
1082 | [2.1.6.2.3] | Yes. | Yes. | If execution of a block throws an event, the appropriate event handler is executed.
1083 | [2.1.6.2.3] | Yes. | Yes. | If a document scope menu grammar is matched while processing another form, control transitions to the target of the the matched <choice> element's next or expr attribute.
1084 | [2.1.6.2.3] | Yes. | Yes. | If a document scope menu grammar is matched while processing another form, the matched <choice> element's event or eventexpr is thrown.
1085 | [2.1.6.2.3] | Yes. | Yes. | If a document scope menu grammar is matched while processing another form and the matched <choice> element's event or eventexpr is thrown and the event handler does not transition to a new form, the FIA resumes in the <menu> after clearing the menu's anonymous form item variable.
1086 | [2.1.6.2.3] | Yes. | Yes. | After a field level grammar is matched, a form level <filled> element will be queued for execution if the field item variable is specified in the namelist of the <filled> element and the mode is "any".
1087 | [2.1.6.2.3] | Yes. | Yes. | After a field level grammar is matched, a form level <filled> element will be queued for execution if the field is the only entry in the namelist and the mode is "all".
1088 | [2.1.6.2.3] | Yes. | Yes. | After a field level grammar is matched, a form level <filled> element will be queued for execution if the namelist is empty and the mode is "any".
1089 | [2.1.6.2.3] | Yes. | Yes. | After a field level grammar is matched, a form level <filled> element will be queued for execution if the namelist is empty, the mode is "all" and the field is the only input item in the form.
1090 | [2.1.6.2.3] | Yes. | Yes. | After a field level grammar is matched, a form level <filled> element will not be queued for execution if the field item variable is not specified in the (non-empty) namelist of the <filled> element.
1091 | [2.1.6.2.3] | Yes. | Yes. | After a field level grammar is matched, a form level <filled> element will not be queued for execution if the namelist of the <filled> element references other input items in addition to this field and the mode is "all".
1092 | [2.1.6.2.3] | Yes. | Yes. | After a field level grammar is matched, a form level <filled> element will not be queued for execution if the namelist is empty, the mode is "all" and the form has other input items.
1093 | [2.1.6.2.3] | Yes. | Yes. | If a form level grammar is matched, field level <filled> elements are queued for execution if and only if the field has just been assigned a value by this input.
1094 | [2.1.6.2.3] | Yes. | Yes. | After a form level grammar is matched, a form level <filled> element will be queued for execution if all the fields listed in the namelist of the <filled> have just been assigned a value.
1095 | [2.1.6.2.3] | Yes. | Yes. | After a form level grammar is matched, a form level <filled> element will be queued for execution if at least one of the fields listed in the namelist of the <filled> has just been assigned a value and the mode is "any".
1096 | [2.1.6.2.3] | Yes. | Yes. | After a form level grammar is matched, a form level <filled> element will be queued for execution if the namelist is empty, the mode is "all" and all input item variables have just been assigned a value.
1097 | [2.1.6.2.3] | Yes. | Yes. | After a form level grammar is matched, a form level <filled> element will be queued for execution if the namelist is empty, the filled mode is "any" and at least one input item variable has just been assigned a value.
1098 | [2.1.6.2.3] | Yes. | Yes. | After a form level grammar is matched, a form level <filled> element will not be queued for execution if the mode is "all" and at least one of the fields listed in the namelist of the <filled> has not just been assigned a value.
1099 | [2.1.6.2.3] | Yes. | Yes. | After a form level grammar is matched, a form level <filled> element will not be queued for execution if none of the fields listed in the namelist of the <filled> has just been assigned a value and the mode is "any" .
1100 | [2.1.6.2.3] | Yes. | Yes. | After a form level grammar is matched, a form level <filled> element will not be queued for execution if the namelist is empty, the mode is "all" and at least one input item variables has not just been assigned a value.
1101 | [2.1.6.2.3] | Yes. | Yes. | After a form level grammar is matched, a form level <filled> element will not be queued for execution if the namelist is empty, the filled mode is "any" and no input item variable has just been assigned a value.
1102 | [2.1.6.2.3] | Yes. | Yes. | If no input items are filled by a user input and no events are thrown, the FIA resumes at the next iteration of the main loop.
1103 | [2.1.6.2.3] | Yes. | Yes. | <goto nextitem> does not reset conditions associated with items in the targeted form.
1104 | [2.1.6.2.3] | Yes. | Yes. | <goto nextitem> does not reset form item variables in the targeted form item.
1105 | [2.1.6.2.3] | Yes. | Yes. | <goto nextitem> will cause the target form item's prompt to be played even if it has already been visited.
1106 | [2.1.6.2.3] | Yes. | Yes. | 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.
1107 | [2.3.3] | Yes. | Yes. | If one or more of a form's field item variables are set by user input, then all <initial> form item variables within the form are set to true, before any <filled> actions are executed.
1108 | [2.3.3] | Yes. | Yes. | If an <initial> form item variable has been explicitly cleared after a previous user input, the <initial> form item variable will only be set when a new grammar match sets a field item variable.
1109 | [2.3.3] | Yes. | Yes. | Grammars with <field> scope are not active within <initial>.
1110 | [2.3.3] | Yes. | Yes. | Explicit assignment of values to input item variables does not affect the value of an <initial>'s form item variable.
1111 | [2.3.3] | Yes. | Yes. | <initial> elements may contain audio prompts, properties , and event handlers.
1112 | [2.3.3] | Yes. | Yes. | When an event is thrown while visiting an <initial> element, the <initial> element is the innermost scope for finding an appropriate event handler, and therefore events may be caught by event handlers specified within the <initial> element.
1113 | [2.3.3] | Yes. | Yes. | <initial> elements have event counters that follow the normal event count semantics.
1114 | [2.3.3] | Yes. | Yes. | <initial> elements collect a user input, i.e. they cause queued prompts to be played, grammars to be activated and a speech recognition process to be started.
1115 | [3.1.6.3] | Yes. | Yes. | Test of example table: form-level result 'hello'.
1116 | [3.1.6.3] | Yes. | Yes. | Test of example table: form-level result '{ x: valueX }'.
1117 | [3.1.6.3] | Yes. | Yes. | Test of example table: form-level result '{ y: valueY }'.
1118 | [3.1.6.3] | Yes. | Yes. | Test of example table: form-level result '{ z: valueZ }'.
1119 | [3.1.6.3] | Yes. | Yes. | Test of example table: form-level result '{ x: valueX , y: valueY , z: valueZ }'.
1120 | [3.1.6.3] | Yes. | Yes. | Test of example table: form-level result '{ a: valueA , b: value B }'.
1121 | [3.1.6.3] | Yes. | Yes. | Test of example table: field-level X result 'hello'.
1122 | [3.1.6.3] | Yes. | Yes. | Test of example table: field-level X result '{ x: valueX }'.
1123 | [3.1.6.3] | Yes. | Yes. | Test of example table: field-level X result '{ y: valueY }'.
1124 | [3.1.6.3] | Yes. | Yes. | Test of example table: field-level X result '{ z: valueZ }'.
1125 | [3.1.6.3] | Yes. | Yes. | Test of example table: field-level X result '{ x: valueX , y: valueY , z: valueZ }'.
1126 | [3.1.6.3] | Yes. | Yes. | Test of example table: field-level X result '{ a: valueA , b: value B }'.
1127 | [3.1.6.3] | Yes. | Yes. | Test of example table: field-level Z result 'hello'.
1128 | [3.1.6.3] | Yes. | Yes. | Test of example table: field-level Z result '{ x: valueX }'.
1129 | [3.1.6.3] | Yes. | Yes. | Test of example table: field-level Z result '{ y: valueY }'.
1130 | [3.1.6.3] | Yes. | Yes. | Test of example table: field-level Z result '{ z: valueZ }'.
1131 | [3.1.6.3] | Yes. | Yes. | Test of example table: field-level Z result '{ x: valueX , y: valueY , z: valueZ }'.
1132 | [3.1.6.3] | Yes. | Yes. | Test of example table: field-level Z result '{ a: valueA , b: value B }'.
1135 | [4.1.3] | Yes. | Yes. | If neither 'src' nor 'expr' are specified on an audio element, an error.badfetch event is thrown.
1138 | [2.1.6.2.1] | Yes. | Yes. | Assigning a form item's variable to undefined via ECMAScript makes it eligible to be visited by the FIA, without resetting the error counters associated with the item.
1139 | [2.1.6.2.3] | Yes. | Yes. | <goto nextitem> does not reset event counters associated with items in the targeted form.
1140 | [2.1.6.2.3] | Yes. | Yes. | <goto nextitem> does not reset prompt counters associated with items in the targeted form.
1141 | [2.3.7.2.2] | No. | No. | Upon termination of a bridged transfer due to the caller matching an active DTMF grammar ('near_end_disconnect'), application.lastresult$ is assigned to the DTMF result.
1143 | [2.1.6.2.3] | Yes. | Yes. | While executing a filled, if a submit is encountered the remaining filled actions are skipped.
1144 | [2.1.6.2.3] | Yes. | Yes. | While executing a filled, if a disconnect is encountered the remaining filled actions are skipped.
1145 | [2.1.6.2.3] | Yes. | No. | While executing a filled, if an exit is encountered the remaining filled actions are skipped.
1146 | [2.1.6.2.3] | Yes. | Yes. | While executing a filled, if a return is encountered the remaining filled actions are skipped.
1147 | [2.1.6.2.3] | Yes. | Yes. | While executing a filled, if a goto is encountered the remaining filled actions are skipped.
1148 | [2.1.6.2.3] | Yes. | Yes. | While executing a filled, if a throw is encountered the remaining filled actions are skipped.
1149 | [5.3.8] | Yes. | Yes. | The interpreter throws "error.badfetch.http.404" if the HTTP server returns a 404 before the fetchtimeout. If, however, the fetchtimeout interval elapses before the server returns a 404, the interpreter throws "error.badfetch".
1150 | [5.3.8] | Yes. | Yes. | If Querystring & namelist variable ,both are mentioned with method GET then both values need to be submitted
1152 | [5.3.13] | Yes. | Yes. | The <log> element may contain any combination of text (CDATA) and <value> elements.
1156 | [2.3.4] | Yes. | Yes. | When the subdialog returns, its execution context is deleted. All subdialog context variable bindings are lost.
1157 | [2.3.4] | Yes. | Yes. | If a subdialog URI has a query string and the subdialog has a namelist attribute the namelist variables are additionally submitted.
1158 | [2.3.4] | Yes. | Yes. | When there is no fragment, the subdialog invoked is the lexically first dialog in the document.
1159 | [2.3.4] | Yes. | Yes. | It is a semantic error to attempt to set a form item variable or an undeclared variable using <param>
1161 | [5.3.13] | Yes. | Yes. | The label attribute may be used, for example, to indicate the purpose of the log.
1162 | [5.3.9] | Yes. | No. | The exit element does not throw an "exit" event.
1163 | [5.3.13] | Yes. | Yes. | When expr is set in a log, the expression evaluated to a string is present in a logging or debug message.
1165 | [2.3.7.2.2] | No. | No. | Upon termination of a bridged transfer due to the caller matching an active speech grammar ('near_end_disconnect'), application.lastresult$.utterance is assigned the same value as the transfer's utterance shadow.
1166 | [2.3.7.2.2] | No. | Yes. | If a bridged transfer is terminated due to a reason other than the caller matching an active speech or DTMF grammar ('near_end_disconnect'), application.lastresult$ is undefined.
1167 | [6.1.1] | Yes. | Yes. | If fetchtimeout is not specified, but a non-empty fetchtimeout property exists, then if content is not returned within the specified fetchtimeout property, an error.badfetch event is thrown.
1168 | [6.1.1] | Yes. | Yes. | If fetchtimeout is not specified, but a non-empty fetchtimeout property exists, then if content is returned within the specified fetchtimeout property, document processing proceeds as normal.
1169 | [5.3.12] | Yes. | Yes. | The <script> element has the charset attributes: The character encoding of the script designated by src. UTF-8 and UTF-16 encodings of ISO/IEC 10646 must be supported (as in [XML]). The default value is UTF-8.
1170 | [6.1.1] | Yes. | Yes. | If a fetchaudio is played during fetch of a document, the play is interrupted when the document is loaded.
1171 | [2.3.1] | Yes. | Yes. | If the specified builtin type is not supported by the platform, an error.unsupported.builtin event is thrown.
1172 | [2.3.1.3] | No. | Yes. | When the accept attribute of an option element is set to "approximate", the user may say a subphrase of the specified PCDATA for the option to be selected.
1173 | [2.2] | Yes. | Yes. | DTMF properties apply to recognition of the DTMF digits specified by dtmf attribute of choice.
1174 | [2.5] | Yes. | Yes. | Any URIs in the content of a link are resolved lexically, i.e. according to the base URI (see xml:base in Section 1.5.1) for the document in which the link is defined.
1175 | [2.5] | Yes. | Yes. | any URIs in an attribute of a link element are resolved dynamically, i.e. according to the base URI in effect when the link s grammar is matched.
1176 | [2.5] | Yes. | Yes. | any ECMAScript expressions in an attribute of a link element are evaluated dynamically, i.e. in the scope and execution context in effect when the grammar is matched.
1179 | [5.3.2] | Yes. | Yes. | When an ECMAScript object, e.g. "obj", has been properly initialized then its properties, for instance "obj.prop1", can be assigned without explicit declaration.
1180 | [2.3.7] | No. | Yes. | A transfer element that specifies both a 'aai' and 'aaiexpr' attribute results in an 'error.badfetch' upon loading of the document containing it.
1181 | [2.3.7.3] | No. | Yes. | If the destination URI is malformed, a error.connection.baddestination error is thrown.
1182 | [2.3.7.3] | No. | Yes. | If the destination URI type is not supported, a error.unsupported.uri error is thrown.
1183 | [2.3.7.3] | No. | No. | If the platform does not support blind transfers, a error.unsupported.transfer.blind error is thrown.
1184 | [2.3.7.3] | No. | No. | If the is insufficient permission to perform a call transfer (e.g. not allowed to make long distance calls, not permitted to make any transfers, etc.), destination URL is malformed, a error.connection.noauthorization error is thrown.
1185 | [5.1.4] | No. | Yes. | The name (session.connection.protocol.name) also represents the subobject name for protocol specific information. For instance, if session.connection.protocol.name is 'q931', session.connection.protocol.q931.uui might specify the user-to-user information property of the connection.

# Appendices

## Appendix A - Test assertion XML API definition

This appendix describes a framework for authoring VoiceXML tests. The framework abstracts the markup used to define interactions with the user, allowing vendors to use their own test infrastructure by applying an XSLT transformation to the test source. Modifications to the test infrastructure should require a change to the XSLT template only followed by re-transformation of the test source.

The test API described in this document uses the complete schema specified in the VoiceXML 2.0 specification with the addition of a set of twelve elements in their own namespace (http://www.w3.org/2002/vxml-conformance) that greatly simplify the process of authoring tests and abstract the implementation details of the testing infrastructure. The elements are divided into four categories:

- A.1 Final status indicators
- A.2 Intermediate status indicators
- A.3 Input operations
- A.4 Grammar definitions

### A.1 Final status indicators

These elements are used to signal the completion of a test and, as such, SHOULD terminate test execution. They can appear anywhere that VXML executable.content is legal (e.g. block, event handlers, filled). Final status tags may be rendered in different ways. The most likely candidates are an exit with a return value, a submit, or a log followed by an exit.

pass
  Indicates successful test completion. A transformation yielding a manually executed test could play the audio "pass" to the user running the test. A transformation yielding an automated test could play a sequence of DTMF tones indicating success to the test driver and submit a pass result to a reporting server. The element is allowed anywhere executable content is allowed in a VoiceXML document.
fail
  Indicates unexpected results from the interpreter. A transformation yielding a manually executed test could play the audio "fail" to the user running the test. A transformation yielding an automated test could play a sequence of DTMF tones indicating failure to the test driver and submit a fail result to a reporting server. The element is allowed anywhere executable content is allowed in a VoiceXML document. The element supports the following optional attributes:

  reason | Optional. A simple text string explaining the probable cause for failure.
  expr | Optional. An ECMAScript expression that evaluates to a string at run-time providing information about the probable cause for failure.

### A.2 Intermediate status indicators

These elements may be used to signal transitions in a multi-part test. They may appear anywhere that VXML executable.content is legal (e.g. block, event handlers, filled). Intermediate status tags may be rendered in different ways. The most likely candidates are using log or prompt or ignoring the element entirely.

comment
  Specifies English language content that describes intermediate test results. The element is allowed anywhere executable content is allowed in a VoiceXML document and may contain plain text and zero or more value elements in any order. Note the following caveats with respect to the comment element:
  - Because the runtime impact is variable, this tag should NOT be used in situations where timing is being tested.
  - Because this tag may be ignored, a test author must take care that expressions specified in the context of the comment element have no runtime impact. For example, setting the expr attribute of the value element to "x = x + 1" within a comment not only displays the value of x but also increments its x. Leveraging such side-effects should be avoided.

### A.3 Input operations

These tags may be used at any point that input is required (e.g. initial, field, record, transfer) or on input-related event handlers (e.g. noinput and nomatch). These elements may be rendered in several different ways A few possibilities include playing DTMF prompts to control an external test driver, using properties to control the recognition result, or using platform-specific test features.

If these tags define prompts, they MUST provide separate prompts with counts 1 through 3.

speech
  Sends a predefined utterance to a user or test driver. The response from the user or driver is expected to be an utterance matching a grammar. The speech element is allowed anywhere audio can be played in a VoiceXML document. Supports the following required attribute:

  value | Required. Uniquely identifies the utterance.

dtmf
  Sends a request to a user or test driver to type or playback one or more DTMF digits. Supports the following required attribute:

  value | Required. The sequence of DTMF digits.

recording
  Sends a request to a user or test driver to speak or playback audio to be recorded by the interpreter via execution of the record element. Supports the following required attribute:

  value | Required. A unique identifier that specifies the desired recording from the user or test driver. The possible values for the attribute include the following:
  nonspeech | The driver must recite a recording at least 5 seconds in length that does not contain one of the predefined utterance. An example is the popular nursery rhyme "Little Miss Muffett".
  alpha, bravo, ... | The driver must recite a recording containing the predefined utterance specified via the value attribute.

noinput
  Requests that the test driver or caller play or say nothing in order to cause the interpreter to generate a noinput event. The optional duration attribute allows you to specify how many seconds the driver or caller should remain silent.
nomatch
  Requests that the test driver or caller play or say something unrecognizable (out of grammar) in order to cause the interpreter to generate a nomatch event. The optional duration attribute allows you to specify how many seconds the driver or caller should provide the input.
hangup
  Requests that the test driver or caller hang up. in order to cause the interpreter to generate a session.disconnect.hangup event.

### A.4 Grammar definitions

Grammars are expected to return one of three classes of results:

- no semantic interpretation
- a simple result
- a structured result.

The utterance attribute specifies which audio input is expected to match this grammar. Grammars may map to a simple result by specifying an interpretation via the interp attribute. More complex results may be returned using the key element.

NOTE: A grammar element may NOT specify an interp attribute and one or more key elements simultaneously.

grammar
  Specifies a grammar to be used when recognition is required by the test. Allowed anywhere a grammar element is allowed in a VoiceXML document. Supports the following attributes:

  utterance | Required. Specifies the unique identifier of an utterance.
  interp | Optional. Specifies a simple result string returned by the interpreter when the utterance is matched.

key
  Supports the following attributes:

  name | Required. The string identifying the key. The string should be a valid ECMAScript variable name. Keys are used to express structured recognition results. Each key may contain either PCDATA or one or more key elements. Multiple keys with the same name may appear; this allows arrays to be built for complex results such as the 'pizza' example.
  value | Optional. A string representing the value the key. If the value is omitted, the key element element MUST contain one or more key elements.

phrase
  Maps to a simple text string. The element is intended for phrase-based grammars such as VoiceXML choice and option elements. The element may also be used to construct SSML prompts. Supports the following required attribute:

  utterance | Specifies the unique identifier of an utterance.

### A.5 Grammar selection

The stylesheet author is required to select eight utterances, represented in the test framework by the first eight symbols in the International Radio Alphabet. In practice, the actual values will be specific to each language and may differ for each recognizer. These words or phrases should be carefully chosen such that speech utterances match corresponding grammars with high confidence scores. For example, setting the value attribute of the speech element to "alpha" should reliably match (i.e. produce a confidence of at least 0.5) a grammar that is rendered when setting the value of the utterance attribute of the grammar element to "alpha". Likewise, speech utterances should either produce low scores or not match grammars corresponding to different utterances. For example, setting the value attribute of the speech element to "alpha" should reliably return a confidence of less that 0.5 when match against the grammar produced by setting the utterance attribute of the grammar element to "bravo".

It should be reiterated that testing recognition accuracy is not a goal of this suite. Hence, the stylesheet author may freely select any eight phrases.

### A.6 Predefined utterances

As defined in the Test API markup, the speech element should be used to request a predefined utterance from the user or test driver. In the document type definition (DTD) below, the 'ir-commands' entity defines the set of valid unique identifiers. The list is easily extended, and the XSLT should be updated to handled additional identifiers when processing the speech, grammar, and phrase elements.

### A.7 Document Type Definition

The following DTD succintly declares the Test API markup elements, their attributes, and the legal values for those attributes if applicable.

    <!ELEMENT conf:pass EMPTY>
    <!ELEMENT conf:fail EMPTY>
    <!ATTLIST conf:fail
       reason CDATA #IMPLIED
       expr CDATA #IMPLIED>

    <!ENTITY % ir-utterances 'alpha|bravo|charlie|delta|echo|foxtrot|golf|hotel'>
    <!ENTITY % ir-commands '%ir-utterances;|help|cancel|exit|yes'>

    <!ELEMENT conf:dtmf EMPTY>
    <!ATTLIST conf:dtmf
       value CDATA #REQUIRED>

    <!ELEMENT conf:hangup   EMPTY >
    <!ELEMENT conf:noinput   EMPTY >
    <!ATTLIST conf:noinput
      duration CDATA #IMPLIED>
    <!ELEMENT conf:nomatch   EMPTY >
    <!ATTLIST conf:nomatch
      duration CDATA #IMPLIED>

    <!ELEMENT conf:recording   EMPTY >
    <!ATTLIST conf:recording
       value (%ir-utterances;|nonspeech) #REQUIRED >

    <!-- Add conf:speech to the menu element decl. -->
    <!ELEMENT conf:speech EMPTY>
    <!ATTLIST conf:speech
       value (%ir-commands;) #REQUIRED>

    <!ELEMENT conf:grammar (conf:key*)>
    <!ATTLIST conf:grammar
      utterance (%ir-utterances;) #REQUIRED
      interp CDATA #IMPLIED
    >

    <!ELEMENT conf:key         (#PCDATA | conf:key)* >
    <!ATTLIST conf:key
       name  CDATA  #REQUIRED
       value  CDATA  #IMPLIED
    >

    <!ELEMENT conf:phrase      EMPTY >
    <!ATTLIST conf:phrase
       utterance   (%ir-commands;) #REQUIRED >

    <!ELEMENT conf:comment (#PCDATA | value)*>

    <!ENTITY % ir-test-ext "conf:pass | conf:fail | conf:comment ">
    <!ENTITY % ir-prompts "conf:speech | conf:dtmf | conf:hangup |
      conf:noinput | conf:nomatch | conf:recording">

To incorporate the test API into the VoiceXML 2.0 DTD to validate test source against the DTD, perform the following steps:

1. Add "xmlns:conf CDATA #IMPLIED" to the ATTLIST declaration of the vxml element.
2. Add the test API ELEMENT and ENTITY declarations listed above to the DTD before the 'executable.content' ENTITY declaration.
3. Add a reference to the 'ir-test-ext' ENTITY to the 'executable.content' ENTITY declaration.
4. Add a reference to the 'ir-prompts' ENTITY to the following ELEMENT declarations: menu, field, initial, record, transfer, subdialog, and object.
5. Add conf:phrase to the choice and option ELEMENT declarations.
6. Add conf:grammar to the 'input' ENTITY declaration and to the link ELEMENT declaration.

Alternatively, you can transform your test source through the XSLT, and validate the output against the VoiceXML 2.0 DTD.

### A.8 Test examples

The following examples illustrate the use of the proposed tags. These examples were written to help validate the stylesheet used to generate the tests. These tests should all pass before the stylesheet is applied to the main body of tests.

#### Example 1

The following example demonstrates simple usage of the conf:pass element. When the block is executed, the transformation of the conf:pass element will be executed.

    <vxml version="2.0" xmlns="http://www.w3.org/2001/vxml"
       xmlns:conf="http://www.w3.org/2002/vxml-conformance">
      <form>
        <block>
          <conf:pass/>
        </block>
      </form>
    </vxml>

#### Example 2

The following example demonstrates simple usage of the conf:fail element. When the block is executed, the transformation of the conf:fail element will be executed.

    <vxml version="2.0" xmlns="http://www.w3.org/2001/vxml"
       xmlns:conf="http://www.w3.org/2002/vxml-conformance">
      <form>
        <block>
          <conf:fail/>
        </block>
      </form>
    </vxml>

#### Example 3

The following example demonstrates usage of the reason attribute of the conf:fail element. When the block is executed, the transformation of the conf:fail element will be executed. Although some interpreters may ignore the reason attribute, others may output the value in a log element or submit it to a server-side script for further processing.

    <vxml version="2.0" xmlns="http://www.w3.org/2001/vxml"
       xmlns:conf="http://www.w3.org/2002/vxml-conformance">
      <form>
        <block>
          <conf:fail reason="roulette"/>
        </block>
      </form>
    </vxml>

#### Example 4

The following example demonstrates usage of the reason attribute of the conf:fail element. When the block is executed, the transformation of the conf:fail element will be executed. Although some interpreters may ignore the expr attribute, others may output the value via a value element contained within a log element. In this example, the expr attribute will evaluate to "pete 3" at runtime.

    <vxml version="2.0" xmlns="http://www.w3.org/2001/vxml"
       xmlns:conf="http://www.w3.org/2002/vxml-conformance">
      <form>
        <block>
          <conf:fail expr="'pete ' + (1 + 2)"/>
        </block>
      </form>
    </vxml>

#### Example 5

The following example demonstrates usage of the reason attribute of the conf:comment element. Although some interpreters may ignore the element, others may output the contents via a log element. Still others may output the contents via a prompt element. In this example, the interpreter should output "The value of x is 2" at runtime.

    <vxml version="2.0" xmlns="http://www.w3.org/2001/vxml"
       xmlns:conf="http://www.w3.org/2002/vxml-conformance">
      <var name="x" expr="1+1"/>
      <form>
        <block>
          <conf:comment>
            The value of x is <value expr="x"/>.
          </conf:comment>
          <conf:pass/>
        </block>
      </form>
    </vxml>

#### Example 6

The following example sends a request to the tester to hangup and catches the connection.disconnect.hangup event. If the event is caught, the interpreter executes the transformation of the conf:pass element. If some other event is executed or no event fires and the block is executed, the transformation of the conf:fail is executed.

    <vxml version="2.0" xmlns="http://www.w3.org/2001/vxml"
       xmlns:conf="http://www.w3.org/2002/vxml-conformance">

      <catch><conf:fail expr="_event"/></catch>

      <form>
        <field name="one">
          <catch event="connection.disconnect.hangup">
            <conf:pass/>
          </catch>
          <catch><conf:fail expr="_event"/></catch>
          <conf:hangup/>
          <conf:grammar utterance="alpha"/>
        </field>

        <block><conf:fail reason="block"/></block>
      </form>
    </vxml>

#### Example 7

The following example sends a request for no input to the tester when field 'one' is executed. If the tester is silent and a noinput event is generated, the noinput handler should execute, and the interpreter should execute the noinput element. If some other event is executed or no event fires and the block is executed, the transformation of the conf:fail is executed.

    <vxml version="2.0" xmlns="http://www.w3.org/2001/vxml"
       xmlns:conf="http://www.w3.org/2002/vxml-conformance">
      <catch><conf:fail reason="catch"/></catch>
      <form>
        <field name="one">
          <noinput><conf:pass/></noinput>
          <catch><conf:fail expr="_event"/></catch>
          <conf:noinput/>
          <conf:grammar utterance="alpha"/>
        </field>

        <block><conf:fail reason="block"/></block>
      </form>
    </vxml>

#### Example 8

The following example sends a request for a nomatch to the tester when field 'one' is executed. If the tester says or plays something out of grammar and a nomatch event is generated, the nomatch handler should execute, and the interpreter should execute the nomatch element. If some other event is executed or no event fires and the block is executed, the transformation of the conf:fail is executed.

    <vxml version="2.0" xmlns="http://www.w3.org/2001/vxml"
       xmlns:conf="http://www.w3.org/2002/vxml-conformance">
      <catch><conf:fail expr="_event"/></catch>
      <form>
        <field name="one">
          <nomatch><conf:pass/></nomatch>
          <catch><conf:fail expr="_event"/></catch>
          <conf:nomatch/>
          <conf:grammar utterance="alpha"/>
        </field>

        <block><conf:fail reason="block"/></block>
      </form>
    </vxml>

#### Example 9

The following example demonstrate the usage of the conf:speech and conf:grammar elements. The conf:speech element is transformed into a series of prompts that correspond to the identifier "alpha". The conf:grammar element is transformed into a simple grammar that corresponds the phrase that matches the alpha utterance mapping. Since the interp attribute of the conf:grammar element is not specified the specific value returned by the interpreter when the grammar is matched cannot be tested. What can be tested is whether or not the form item variable one is defined. The block following the field peforms that check.

    <vxml version="2.0" xmlns="http://www.w3.org/2001/vxml"
       xmlns:conf="http://www.w3.org/2002/vxml-conformance">

      <catch><conf:fail expr="_event"/></catch>

      <form>
        <block>
          <if cond="one != undefined">
            <conf:fail reason="initial check"/>
          </if>
        </block>

        <field name="one">
          <conf:speech value="alpha"/>
          <conf:grammar utterance="alpha"/>
        </field>

        <block>
          <if cond="one != undefined"><conf:pass/></if>
          <conf:fail reason="field assignment"/>
        </block>
      </form>
    </vxml>

#### Example 10

The following example demonstrates usage of the interp attribute of the conf:grammar element. If the tester utters the phrase that corresponds to "alpha", the interpreter recognizes the utterance and fills the form item variable one with the value of the interp attribute. When the block following the field is executed, the if element evaluates to true, and the transformation of the conf:pass element is executed.

    <vxml version="2.0" xmlns="http://www.w3.org/2001/vxml"
       xmlns:conf="http://www.w3.org/2002/vxml-conformance">

      <catch><conf:fail reason="catch"/></catch>

      <form>
        <block>
          <if cond="one != undefined">
            <conf:fail reason="initial check"/>
          </if>
        </block>

        <field name="one">
          <conf:speech value="alpha"/>
          <conf:grammar utterance="alpha" interp="peña"/>
        </field>

        <block>
          <if cond="one=='peña'"><conf:pass/></if>
          <conf:fail reason="field assignment"/>
        </block>
      </form>
    </vxml>

#### Example 11

The following example demonstrates usage of the conf:key element to generate a structured result from a grammar. The conf:speech element instructs the tester to speak or play the utterance that corresponds to the identifier alpha. Upon recognition of this utterance, the interpreter should assign a reference to an object to the form item variable 'one'. The object should have properties x and y with the respective values 'valX' and 'valY'.

    <vxml version="2.0" xmlns="http://www.w3.org/2001/vxml"
       xmlns:conf="http://www.w3.org/2002/vxml-conformance">

      <catch><conf:fail expr="_event"/></catch>

      <form>
        <block>
          <if cond="one != undefined">
            <conf:fail reason="initial check"/>
          </if>
        </block>

        <field name="one">
          <conf:speech value="alpha"/>
          <conf:grammar utterance="alpha">
            <conf:key name="x" value="valX"/>
            <conf:key name="y" value="valY"/>
          </conf:grammar>
        </field>

        <block>
          <if cond="typeof one == 'object' &amp;amp;&amp;amp; one.x == 'valX' &amp;amp;&amp;amp; one.y == 'valY'"><conf:pass/></if>
          <conf:fail reason="field assignment"/>
        </block>
      </form>

    </vxml>

#### Example 12

The following example demonstrates more complex usage of the conf:key element to generate a structured result from a grammar. The conf:speech element instructs the tester to speak or play the utterance that corresponds to the identifier alpha. Upon recognition of this utterance, the interpreter should assign a reference to an object to the form item variable 'one'. The object should have properties x and y. x is a reference to an object and y is assigned the value 'valY'. The object referred to by x has properties a and b with respective values 'valA' and 'valB'.

    <vxml version="2.0" xmlns="http://www.w3.org/2001/vxml"
       xmlns:conf="http://www.w3.org/2002/vxml-conformance">

      <catch><conf:fail expr="_event"/></catch>

      <form>
        <block>
          <if cond="one != undefined">
            <conf:fail reason="initial check"/>
          </if>
        </block>

        <field name="one">
          <conf:speech value="alpha"/>
          <conf:grammar utterance="alpha">
            <conf:key name="x">
              <conf:key name="a" value="valA"/>
              <conf:key name="b" value="valB"/>
            </conf:key>
            <conf:key name="y" value="valY"/>
          </conf:grammar>
        </field>

        <block>
          <if cond="typeof one != 'object'">
            <conf:fail reason="one is not an object"/>
          <elseif cond="one.y != 'valY'"/>
            <conf:fail reason="one.y had bad value"/>
          <elseif cond="typeof one.x != 'object'"/>
            <conf:fail reason="one.x is not an object"/>
          <elseif cond="typeof one.x.a != 'valA'"/>
            <conf:fail reason="one.x.a had bad value"/>
          <elseif cond="typeof one.x.b != 'valB'"/>
            <conf:fail reason="one.x.b had bad value"/>
          <else/>
            <conf:pass/>
          </if>
        </block>
      </form>

    </vxml>

#### Example 13

The following example demonstrates the use of the conf:phrase element to build a locale-independent menu.

    <vxml version="2.0" xmlns="http://www.w3.org/2001/vxml"
       xmlns:conf="http://www.w3.org/2002/vxml-conformance">

      <catch event="menu-done"> <conf:pass/> </catch>
      <catch><conf:fail reason="catch"/></catch>

      <menu>
        <conf:speech value="alpha"/>
        <choice event="menu-done">
          <conf:phrase utterance="alpha"/>
        </choice>
      </menu>

    </vxml>

### A.9 Sample XSLT Template Definition

The following is a listing of an XSLT that can be used to transform the previous example into a valid VoiceXML 2.0 document.

    <?xml version="1.0"?>
    <!-- Copyright 1998-2003 W3C (MIT, ERCIM, Keio), All Rights Reserved. See http://www.w3.org/Consortium/Legal/. -->
    <xsl:stylesheet
        xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
        xmlns:conf="http://www.w3.org/2002/vxml-conformance"
        xmlns="http://www.w3.org/2001/vxml"
        version="1.0">

    <xsl:output cdata-section-elements="script"/>

    <!-- ############################################# -->
    <!-- D o c u m e n t   H e a d e r s               -->
    <!-- ############################################# -->

    <xsl:template match="/">
      <xsl:apply-templates select="/vxml" />
    </xsl:template>

    <!-- Copy everything doesn't match the other rules -->
    <xsl:template match="/ | @* | node()">
      <xsl:copy>
        <xsl:apply-templates select="@* | node()"/>
      </xsl:copy>
    </xsl:template>

    <!-- strip comments -->
    <xsl:template match="comment()"/>

    <!-- ############################################# -->
    <!-- F i n a l   S t a t u s   I n d i c a t o r s -->
    <!-- ############################################# -->

    <!-- Success criteria -->
    <xsl:template match="conf:pass">
      <prompt>pass</prompt>
      <exit/>
    </xsl:template>

    <!-- Failure criteria -->
    <xsl:template match="conf:fail">
      <prompt>fail</prompt>
      <!-- the following only comes up in case of failure -->
      <xsl:if test="@reason != ''">
        <log>failure reason: <xsl:value-of select="@reason"/></log>
        <prompt><xsl:value-of select="@reason"/></prompt>
      </xsl:if>
      <xsl:if test="@expr != ''">
        <log>failure expression: <value expr="{@expr}"/></log>
        <prompt><value expr="{@expr}"/></prompt>
      </xsl:if>
      <exit/>
    </xsl:template>

    <!-- ############################################# -->
    <!-- I n t e r m e d i a t e   R e p o r t s       -->
    <!-- ############################################# -->

    <!-- Copy everything doesn't match the other rules -->
    <xsl:template match="conf:comment">
      <log>
        <xsl:apply-templates />
      </log>
    </xsl:template>

    <!-- ############################################# -->
    <!-- I n p u t   I n d i c a t o r s               -->
    <!-- ############################################# -->

    <xsl:template match="conf:hangup">
      <prompt> Hang up now. </prompt>
    </xsl:template>

    <!-- Recite a recording that DOES contain the specified speech command (alpha, bravo, etc) -->
    <xsl:template match="conf:recording[@value]">
      <prompt count="1">
        Recite a sentence containing the word
        '<xsl:call-template name="emit-name-from-token">
            <xsl:with-param name="token" select="@value"/>
          </xsl:call-template>'.
      </prompt>
      <prompt count="2">
        Recite a sentence containing the word
        '<xsl:call-template name="emit-name-from-token">
            <xsl:with-param name="token" select="@value"/>
          </xsl:call-template>' again.
      </prompt>
      <prompt count="3">
        Recite a sentence containing the word
        '<xsl:call-template name="emit-name-from-token">
            <xsl:with-param name="token" select="@value"/>
          </xsl:call-template>' one more time.
      </prompt>
    </xsl:template>

    <!-- Recite a recording at least 5 seconds in length that
      does NOT contain a well-defined speech command (alpha, bravo, etc) -->
    <!-- Little Miss Muffett sat on her tuffett, eating her curds and whey.
      Along came a spider ... -->
    <!-- Jack and Jill went up the hill to fetch a pail of water.
      Jack fell down and broke his crown ... -->
    <xsl:template match="conf:recording[@value='nonspeech']">
      <prompt count="1">
        Recite your favorite nursery rhyme, for example, 'Little Miss Muffett'.
      </prompt>
      <prompt count="2"> Recite your favorite nursery rhyme again.</prompt>
      <prompt count="3"> Recite your favorite nursery rhyme one more time.</prompt>
    </xsl:template>

    <xsl:template match="conf:noinput">
      <prompt count="1"> No input expected. Say nothing
        <xsl:if test="@duration"> for <xsl:value-of select="@duration"/> seconds</xsl:if>.
      </prompt>
      <prompt count="2"> No input expected. Say nothing again
        <xsl:if test="@duration"> for <xsl:value-of select="@duration"/> seconds</xsl:if>.
      </prompt>
      <prompt count="3"> No input expected. Say nothing one more time
        <xsl:if test="@duration"> for <xsl:value-of select="@duration"/> seconds</xsl:if>.
      </prompt>
    </xsl:template>

    <xsl:template match="conf:nomatch">
      <prompt count="1"> Say something unrecognizable
        <xsl:if test="@duration"> for <xsl:value-of select="@duration"/> seconds</xsl:if>.
      </prompt>
      <prompt count="2"> Say something unrecognizable again
        <xsl:if test="@duration"> for <xsl:value-of select="@duration"/> seconds</xsl:if>.
      </prompt>
      <prompt count="3"> Say something unrecognizable one more time
        <xsl:if test="@duration"> for <xsl:value-of select="@duration"/> seconds</xsl:if>.
      </prompt>
    </xsl:template>

    <xsl:template match="*[name()='nomatch']/conf:speech[@value]" priority="2">
       <xsl:call-template name="emit-prompt">
         <xsl:with-param name="value"><xsl:value-of select="@value"/></xsl:with-param>
       </xsl:call-template>
    </xsl:template>

    <xsl:template match="*[name()='noinput']/conf:speech[@value]" priority="2">
       <xsl:call-template name="emit-prompt">
         <xsl:with-param name="value"><xsl:value-of select="@value"/></xsl:with-param>
       </xsl:call-template>
    </xsl:template>

    <xsl:template match="*[name()='block']/conf:speech[@value]" priority="2">
       <xsl:call-template name="emit-prompt">
         <xsl:with-param name="value"><xsl:value-of select="@value"/></xsl:with-param>
       </xsl:call-template>
    </xsl:template>

    <xsl:template match="conf:speech[@value]">
       <xsl:call-template name="emit-prompt">
         <xsl:with-param name="value"><xsl:value-of select="@value"/></xsl:with-param>
         <xsl:with-param name="taper">1</xsl:with-param>
       </xsl:call-template>
    </xsl:template>

    <xsl:template match="*[name()='nomatch']/conf:dtmf[@value]" priority="2">
       <xsl:call-template name="emit-dtmf">
         <xsl:with-param name="value"><xsl:value-of select="@value"/></xsl:with-param>
         <xsl:with-param name="taper">0</xsl:with-param>
       </xsl:call-template>
    </xsl:template>

    <xsl:template match="*[name()='noinput']/conf:dtmf[@value]" priority="2">
       <xsl:call-template name="emit-dtmf">
         <xsl:with-param name="value"><xsl:value-of select="@value"/></xsl:with-param>
         <xsl:with-param name="taper">0</xsl:with-param>
       </xsl:call-template>
    </xsl:template>

    <xsl:template match="*[name()='block']/conf:dtmf[@value]" priority="2">
       <xsl:call-template name="emit-dtmf">
         <xsl:with-param name="value"><xsl:value-of select="@value"/></xsl:with-param>
         <xsl:with-param name="taper">0</xsl:with-param>
       </xsl:call-template>
    </xsl:template>

    <xsl:template match="conf:dtmf[@value]">
       <xsl:call-template name="emit-dtmf">
         <xsl:with-param name="value"><xsl:value-of select="@value"/></xsl:with-param>
         <xsl:with-param name="taper">1</xsl:with-param>
       </xsl:call-template>
    </xsl:template>

    <!-- ############################################# -->
    <!-- G r a m m a r s                               -->
    <!-- ############################################# -->

    <xsl:template match="conf:grammar[@interp and @utterance]" priority="2">
    <xsl:variable name="rootname">CityName<xsl:value-of select="generate-id()"/></xsl:variable>
    <grammar type="application/srgs+xml" root="{$rootname}" version="1.0">
      <rule id="{$rootname}" scope="public">
      <one-of>
         <item>
           <xsl:call-template name="emit-utterance">
             <xsl:with-param name="utterance"><xsl:value-of select="@utterance"/></xsl:with-param>
           </xsl:call-template>
          <tag>'<xsl:value-of select="@interp"/>'</tag>
        </item>
      </one-of>
      </rule>
    </grammar>
    </xsl:template>

    <!-- an utterance without an explicit interpretation -->
    <xsl:template match="conf:grammar[@utterance]" priority="1">
    <xsl:variable name="rootname">CityName<xsl:value-of select="generate-id()"/></xsl:variable>
    <grammar type="application/srgs+xml" root="{$rootname}" version="1.0">
      <rule id="{$rootname}" scope="public">
      <one-of>
        <item>
          <xsl:call-template name="emit-utterance">
             <xsl:with-param name="utterance"><xsl:value-of select="@utterance"/></xsl:with-param>
          </xsl:call-template>
        </item>
      </one-of>
      </rule>
    </grammar>
    </xsl:template>

    <xsl:template match="conf:grammar[@utterance and descendant::conf:key]" priority="2">
    <xsl:variable name="rootname">CityName<xsl:value-of select="generate-id()"/></xsl:variable>
    <grammar type="application/srgs+xml" root="{$rootname}" version="1.0">
      <rule id="{$rootname}" scope="public">
      <one-of>
        <item>
          <xsl:call-template name="emit-utterance">
             <xsl:with-param name="utterance"><xsl:value-of select="@utterance"/></xsl:with-param>
          </xsl:call-template>

        <tag>
          <xsl:apply-templates select="conf:key"/>
        </tag>
        </item>
      </one-of>
      </rule>
    </grammar>
    </xsl:template>

    <xsl:template match="conf:key[@value]" priority="2">
      <xsl:param name="path"/>
      <xsl:choose>
      <xsl:when test="$path = ''">
        <xsl:text>var </xsl:text>
      </xsl:when>
      <xsl:when test="$path != ''">
        <xsl:value-of select="$path"/><xsl:text>.</xsl:text>
      </xsl:when>
     </xsl:choose>

      <xsl:value-of select="@name"/>
      <xsl:text>='</xsl:text>
      <xsl:value-of select="@value"/>
      <xsl:text>'; </xsl:text>
    </xsl:template>

    <xsl:template match="conf:key" priority="1">
      <xsl:param name="path"/>
     <xsl:choose>
      <xsl:when test="$path = ''">
        <xsl:text>var </xsl:text>
      </xsl:when>
      <xsl:when test="$path != ''">
        <xsl:value-of select="$path"/><xsl:text>.</xsl:text>
      </xsl:when>
    </xsl:choose>
      <xsl:value-of select="@name"/><xsl:text>=new Object(); </xsl:text>
      <xsl:apply-templates select="conf:key">
        <xsl:with-param name="path">
          <xsl:if test="$path != ''">
            <xsl:value-of select="$path"/><xsl:text>.</xsl:text>
          </xsl:if>
          <xsl:value-of select="@name"/>
        </xsl:with-param>
      </xsl:apply-templates>
    </xsl:template>

    <xsl:template match="conf:phrase[@utterance]">
       <xsl:call-template name="emit-name-from-token">
         <xsl:with-param name="token" select="@utterance"/>
       </xsl:call-template>
    </xsl:template>

    <!-- ############################################# -->
    <!-- H e l p e r  T e m p l a t e s                            -->
    <!-- ############################################# -->

    <!-- for use in building grammars -->
    <xsl:template name="emit-utterance">
    <xsl:param name="utterance"/>
      <xsl:choose>
      <xsl:when test="$utterance='alpha'">chicago</xsl:when>
      <xsl:when test="$utterance='bravo'">san francisco</xsl:when>
      <xsl:when test="$utterance='charlie'">new york</xsl:when>
      <xsl:when test="$utterance='delta'">london</xsl:when>
      <xsl:when test="$utterance='echo'">tokyo</xsl:when>
      <xsl:when test="$utterance='foxtrot'">truth or consequences</xsl:when>
      <xsl:when test="$utterance='golf'">hackensack</xsl:when>
      <xsl:when test="$utterance='hotel'">standardsville</xsl:when>
      <xsl:when test="$utterance='help'">help</xsl:when>
      <xsl:when test="$utterance='cancel'">cancel</xsl:when>
      <xsl:when test="$utterance='exit'">exit</xsl:when>
      <xsl:when test="$utterance='yes'">yes</xsl:when>
      </xsl:choose>
    </xsl:template>
    <!-- Truth or Consequences is a real city in New Mexico, US.  Hackensack
         is located in New Jersey, US very close to the site of the Sept. 2001
         face-to-face.   And finally, yes, there really is a Standardsville.
         It's in Greene County, Virginia, US. -->

    <!-- for use in building prompts -->
    <xsl:template name="emit-name-from-token">
    <xsl:param name="token"/>
      <xsl:choose>
        <xsl:when test="$token = 'alpha'">Chicago</xsl:when>
        <xsl:when test="$token = 'bravo'">San Francisco</xsl:when>
        <xsl:when test="$token = 'charlie'">New York</xsl:when>
        <xsl:when test="$token = 'delta'">London</xsl:when>
        <xsl:when test="$token = 'echo'">Tokyo</xsl:when>
        <xsl:when test="$token = 'foxtrot'">Truth or Consequences</xsl:when>
        <xsl:when test="$token = 'golf'">Hackensack</xsl:when>
        <xsl:when test="$token = 'hotel'">Standardsville</xsl:when>
        <xsl:when test="$token = 'help'">help</xsl:when>
        <xsl:when test="$token = 'cancel'">cancel</xsl:when>
        <xsl:when test="$token = 'exit'">exit</xsl:when>
        <xsl:when test="$token = 'yes'">yes</xsl:when>
      </xsl:choose>
    </xsl:template>

    <xsl:template name="emit-prompt">
      <xsl:param name="value"/>
      <xsl:param name="taper">0</xsl:param>

      <xsl:variable name="text_mapping">
        <xsl:call-template name="emit-name-from-token">
          <xsl:with-param name="token" select="$value"/>
        </xsl:call-template>
      </xsl:variable>

      <xsl:choose>
      <xsl:when test="$taper = 1">
        <prompt count="1">
          Say '<xsl:value-of select="$text_mapping"/>'.
        </prompt>
        <prompt count="2">
          Say '<xsl:value-of select="$text_mapping"/>' again.
        </prompt>
        <prompt count="3">
          Say '<xsl:value-of select="$text_mapping"/>' one more time.
        </prompt>
      </xsl:when>
      <xsl:otherwise>
        <prompt>
          Say '<xsl:value-of select="$text_mapping"/>'.
        </prompt>
       </xsl:otherwise>
      </xsl:choose>
    </xsl:template>

    <xsl:template name="emit-dtmf">
      <xsl:param name="value"/>
      <xsl:param name="taper">0</xsl:param>

      <xsl:choose>
      <xsl:when test="$taper = 1">
        <prompt count="1"> Press '<xsl:value-of select="@value"/>'. </prompt>
        <prompt count="2"> Press '<xsl:value-of select="@value"/>' again. </prompt>
        <prompt count="3"> Press '<xsl:value-of select="@value"/>' one more time. </prompt>
      </xsl:when>
      <xsl:otherwise>
        <prompt> Press '<xsl:value-of select="$value"/>'. </prompt>
      </xsl:otherwise>
      </xsl:choose>

    </xsl:template>

    </xsl:stylesheet>

### A.10 Transformation output

The following is a listing of the output of Example 9 when transformed through the provided XSLT.

    <vxml version="2.0" xmlns="http://www.w3.org/2001/vxml">
      <catch>
        <log>failure expression:
        <value expr="_event" />
        </log>
        <audio>fail</audio>
        <exit />
      </catch>

      <form>
        <block>
          <if cond="one != undefined">
            <log>failure reason: initial check</log>
            <audio>fail</audio>
            <exit />
          </if>
        </block>

        <field name="one">
          <prompt count="1">Say 'Chicago'.</prompt>
          <prompt count="2">Say 'Chicago' again.</prompt>
          <prompt count="3">Say 'Chicago' one more time.</prompt>

          <grammar type="application/grammar+xml" root="CityName">
            <rule id="CityName" scope="public">
              <one-of>
                <item>Chicago</item>
              </one-of>
            </rule>
          </grammar>
        </field>

        <block>
          <if cond="one != undefined">
            <audio>pass</audio>
            <exit />
          </if>
          <log>failure reason: field assignment</log>
          <audio>fail</audio>
          <exit />
        </block>
      </form>
    </vxml>

## Appendix B - Abstract CGI (IRCGI) API definition

The VoiceXML 2.0 Implementation Report contains assertions that require server-side support to verify HTTP headers and submitted values. To allow disparate test environments to use different server-side technologies, tests describe the server-side processing using a syntax independent of any particular server-side framework.

This appendix describes a server-agnostic XML API that can be transformed easily using XSLT into any server-side framework. Reference Perl and JSP XSLT templates are provided as examples.

The API supports the following:

- Verification of the method used to make the HTTP request (GET, POST, etc).
- Verification of the presence and value of one or more HTTP headers.
- Verification of the presence and value of one ore more submitted parameters.
- Verification of the presence and value of method, headers, and parameters.
- Returning a specific HTTP response status code.
- Returning VoiceXML containing the next ".vxml" document to be visited.
- Sleeping for a specified number of seconds before returning a response.
- Setting an Expires response header based on a specified delta.

The XML API does not require the following:

- State management.
- Indicating test pass or failure.

### B.1 Processing Model

A document conforming to this specification, heretofore referred to as an "IRCGI document", indicates the checks to be made on an HTTP request. Supported checks include:

- HTTP method
- Request headers
- Parameters

Checks may be nested. The result of the checks determines the next document to be executed. The next document must continue the test and must determine the success or failure of the test. Once the IRCGI document determines the next document, a response is sent, and the IRCGI document terminates.

### B.2 Syntax

An IRCGI document consists of the following elements. The DTD can be found below.

ircgi
  The root document element. This element must appear as the root document element for all IRCGI documents.
comment
  Contains comments that may be accumulated during CGI execution. The comments may be returned in one or more log elements in the body of the HTTP response. This may be used as a primitive debugging facility.
if-header
  Checks for the presence and value of an HTTP request header. Supports the following attributes:

  name | Requird. The name of the header. If only the name attribute is specified, the CGI must execute the if-header content only if the named header is present in the request.
  value | Optional. The expected value of the header. If this attribute is specified, the CGI must execute the if-header content only if the named header is present in the request and its value matches that of the value attribute. This attribute and the starts-with attribute are mutually exclusive.
  starts-with | Optional. The expected value with which the header begins. If this attribute is specified, the CGI must execute the if-header content only if the named header is present in the request and its value begins with the value of the starts-with attribute. This attribute and the value attribute are mutually exclusive.
  ignore-case | Optional. The value match is case-sensitive if the ignore-case attribute is false, the default. The match is not case-sensitive if the attribute is true.

if-method
  Checks the HTTP method used to submit request. The CGI must execute the if-method content only if the type attribute's value matches the HTTP method used to submit the request. The match is case-insensitive.

  type | Required. The HTTP method. Typically 'get' or 'post'.

if-parameter
  Checks for the presence and value of an HTTP request parameter. Supports the following attributes:

  name | Required. The parameter's name. If only the name attribute is specified, the CGI must execute the if-parameter content only if the named parameter is present in the request. This attribute and the starts-with attribute are mutually exclusive.
  value | Optional. The parameter's expected value. If this attribute is specified, the CGI must execute the if-parameter content only if the named parameter is present in the request and its value matches that of the value attribute.
  starts-with | Optional. The expected value with which the parameter begins. If this attribute is specified, the CGI must execute the if-parameter content only if the named parameter is present in the request and its value begins with the value of the starts-with attribute. This attribute and the value attribute are mutually exclusive.
  ignore-case | Optional. The value match is case-sensitive if the ignore-case attribute is false, the default. The match is not case-sensitive if the attribute is true.

next
  Selects the next .vxml document and, optionally, sets the HTTP response code. The CGI must generate a response upon executing a next element and must not execute any other elements.

  code | Optional. The HTTP response code. If the code attribute is specified, its value must be used as the HTTP response status code. The default is 200 (Ok).
  dest | Optional. The URL of the next document. If this attribute is specified, its value must be used by the response to designate the next document to be visited.
  include | Optional. true or false If this attribute is true, the document specified by the dest attribute is returned as the result document. If this attribute is false, the default, the CGI returns a generated VoiceXML document that contains a goto to the document specified by dest. The document generated when include is false may contain the content of comment elements that were encountered. Only files that are in the directory immediately above the cgi-bin directory (see Usage below) may be included. Attempts to include other files result in an HTTP 403 (Forbidden) response status code.
  sleep | Optional. An interval for the CGI to sleep before returning its response to the client.
  expires | Optional. Sets an Expires HTTP response header to a date calculated by adding the value of the expires attribute to the current time. The value of this attribute should be a positive or negative integer in seconds.

### B.3 IRCGI Document Type Definition

The following DTD succintly declares the IRCGI API markup elements, their attributes, and the legal values for those attributes if applicable.

    <!ENTITY % ir-checks "if-header | if-method | if-parameter" >

    <!ELEMENT ircgi (comment | %ir-checks; | next)*>

    <!ELEMENT comment (#PCDATA) >

    <!ELEMENT if-parameter (comment | %ir-checks; | next)* >
    <!ATTLIST if-parameter
      name CDATA #REQUIRED
      value CDATA #IMPLIED
      starts-with CDATA #IMPLIED
      ignore-case (true|false) "false" >

    <!ELEMENT if-header (comment | %ir-checks; | next)* >
    <!ATTLIST if-header
      name CDATA #REQUIRED
      value CDATA #IMPLIED
      starts-with CDATA #IMPLIED
      ignore-case (true|false) "false" >

    <!ELEMENT if-method (comment | %ir-checks; | next)* >
    <!ATTLIST if-method
      type (get|post) "get" >

    <!ELEMENT next EMPTY>
    <!ATTLIST next
      code CDATA "200"
      dest CDATA #IMPLIED
      include (true|false) "false"
      sleep CDATA #IMPLIED
      expires CDATA #IMPLIED>

### B.4 Test examples

The following examples illustrate the use of the IRCGI API elements. The examples validate the XSLT used to generate valid CGI from the test source. These tests should all pass before the XSLT is applied to the main body of tests.

#### Example 1 - Verifying HTTP method

If the HTTP method used is "POST", the next document is "pass.vxml". Otherwise, the next document is "fail.vxml". The match on method name is case-insensitive.

    <?xml version="1.0"?>
    <!-- Check if request method was 'POST'. -->
    <ircgi>
      <if-method value="post">
        <next dest="pass.vxml" />
      </if-method>
      <next dest="fail.vxml" />
    </ircgi>

#### Example 2 - Verifying parameter presence

If the parameter "p1" was submitted, the next document is "pass.vxml". Otherwise, the next document is "fail.vxml". The value of "p1" does not matter because the value attribute was specified.

    <?xml version="1.0"?>
    <!--Check if parameter p1 is present.
    -->
    <ircgi>
      <if-parameter name="p1">
          <next dest="../pass.vxml" />
      </if-parameter>
      <next dest="../fail.vxml" />
    </ircgi>

#### Example 3 - Verifying parameter values

If parameter "p1" has the value "42" and if parameter "p2" has the value "quiche", the next document is "pass.vxml". Otherwise, the next document is "fail.vxml".

This document includes comment elements whose content may be included in a log element in the response document to aid in debugging.

    <?xml version="1.0"?>
    <!-- Check if p1 ==  42 and p2 == 'quiche'. -->
    <ircgi>
      <if-parameter name="p1" value="42">
        <comment>p1 is 42.</comment>
        <if-parameter name="p2" value="quiche">
          <comment> p2 is quiche.</comment>
          <next dest="../pass.vxml" />
        </if-parameter>
        <comment> p2 is not quiche.</comment>
        <next dest="../fail.vxml" />
      </if-parameter>
      <comment>p1 is not 42.</comment>
      <next dest="../fail.vxml" />
    </ircgi>

#### Example 4 - Verifying header presence and value

If the "User-Agent" HTTP header is present but is empty, the next document is "fail.vxml". If the "User-Agent" header is present and not empty, the next document is "pass.vxml". If the "User-Agent" header is not present, the next document is "fail.vxml".

    <?xml version="1.0" ?>
    <ircgi>
      <if-header name="User-Agent">
        <if-header name="User-Agent" value="" >
          <comment>
            User-Agent header present, but empty.
          </comment>
          <next dest="../fail.vxml" />
        </if-header>
        <comment>
          User-Agent header was supplied and not empty.
        </comment>
        <next dest="../pass.vxml" />
      </if-header>
      <comment>
        User-Agent header was not supplied.
      </comment>
      <next dest="../fail.vxml" />
    </ircgi>

#### Example 5 - Setting HTTP response status code

If the parameter "p1" was submitted, the next document is "pass.vxml". Otherwise, the HTTP response code is set to "404".

    <?xml version="1.0"?>
    <!-- Send 404 if p1 not present -->
    <ircgi>
      <if-parameter name="p1">
        <next dest="../pass.vxml" />
      </if-parameter>
      <next code="404" />
    </ircgi>

#### Example 6 - Included and generated result documents

If the parameter "p1" was "include", then parameter "p2" will be checked. If parameter "p2" was "pass", then the response will be the content of the file "pass.vxml" because the next element's include attribute is true. If parameter "p2" is not "pass", the response will be the content of the file "fail.vxml" because the next element's include attribute is false.

If parameter "p1" was not "include", the response document will be generated by the ircgi and include a goto to "fail.vxml" because the include attribute was false, by default. The generated document may contain a log element containing the content of the IRCGI document's comment element.

    <?xml version="1.0"?>
    <!-- If p1 == 'include', include 'pass.vxml' if p2 == 'pass'. -->
    <ircgi>
      <if-parameter name="p1" value="include">
        <if-parameter name="p2" value="pass">
          <next dest="../pass.vxml" include="true"/>
        </if-parameter>
        <next dest="../fail.vxml" include="true" />
      </if-parameter>
      <comment>p1 is not 'include'.</comment>
      <next dest="../fail.vxml" />
    </ircgi>

#### Example 7 - Sleeping before returning a response

This example navigates to a document "fail.vxml" after sleeping for five seconds.

    <?xml version="1.0"?>
    <ircgi>
      <next dest="../fail.vxml" sleep="5" />
    </ircgi>

#### Example 8 - Using starts-with

This example checks the Content-Type header for a partial match on "multipart/form-data".

The starts-with attribute is used instead of the value attribute since the boundary portion of the value cannot be controlled or predetermined. An example of a Content-Type header value when the encoding is set to "multipart/form-data" follows:

    multipart/form-data; boundary=---------------------------7d39216110392

    <ircgi>
      <if-header name="Content-Type">
        <if-header name="Content-Type" starts-with="multipart/form-data" ignore-case="true">
          <next dest="../pass.vxml" />
        </if-header>
        <comment>
          Content-Type header was not multipart/form-data .
        </comment>
        <next dest="../fail.vxml" />
      </if-header>
      <next dest="../fail.vxml" />
    </ircgi>

#### Example 9 - Returning the server-calculated epoch

The following example includes a .js document. The .js document includes a single statement that sets a variable to the value of the special variable __EPOCH__. At runtime, the CGI detects the special variable and replaces it with the server-calculated number of seconds since 'the epoch'. This feature is useful in testing to verify the caching behavior of a VoiceXML interpreter by making multiple IRCGI requests and comparing the values of __EPOCH__. If the values differ, the document was fetched from the Web. If not, the document was retrieved from the browser's local cache.

The IRCGI follows:

    <ircgi>
      <next sleep="2" dest="../epoch.js" include="true"/>
    </ircgi>

The .js document follows:

    var epoch = __EPOCH__;

#### Example 10 - Setting Expires

This example returns the document "cache_me.vxml" along with an Expires header set to 60 seconds after the CGI is requested.

    <ircgi>
      <next dest="../cache_me.vxml" include="true" expires="60"/>
    </ircgi>

### B.5 Usage

For security purposes, transformed IRCGI documents are deployed to an isolated directory, named "cgi-bin" under the assertion directory. Other, non-IRCGI, server-side programs that may be needed are also located in the "cgi-bin" directory.

### B.6 Transformation requirements

The source IRCGI documents must be transformed into files that are executable in the test environment, such as Perl or JSP files. The output files must reside in the "cgi-bin" directory and must have the ".ircgi" file extension. The file extension must be ".ircgi" because this is how other test documents (.txml) will refer to them. The .txml to .vxml transformation process cannot automatically change ".ircgi" ".pl" or ".jsp" because some tests may use ECMAScript expressions to build the reference to the ".ircgi" document.

### B.7 Reference XSLT documents

Two sample XSL stylesheets are provided.

The following XSLT document can be used to transform an IRCGI document to JSP:

    <?xml version="1.0"?>
    <!-- Copyright 1998-2003 W3C (MIT, ERCIM, Keio), All Rights Reserved. See http://www.w3.org/Consortium/Legal/. -->
    <!--  Transforms an ircgi test file into a Java Server Page.-->
    <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
    <xsl:output method="text"/>

    <xsl:template match="/" >
      <xsl:apply-templates />
    </xsl:template>

    <xsl:template match="ircgi">
      <xsl:call-template name="header" />
      <xsl:call-template name="declarations" />
      <xsl:call-template name="determineResult" />
    </xsl:template>

    <!--   Official contentType is 'application/voicexml+xml'.  Change contentType to 'text/xml' to view generated JSP in IE.
     -->
    <xsl:template name="header" >&lt;%@ page language="java" contentType="text/xml" %>
    &lt;%@ page import="java.io.BufferedInputStream" %>
    &lt;%@ page import="java.io.BufferedReader" %>
    &lt;%@ page import="java.io.InputStreamReader" %>
    &lt;%@ page import="java.net.URL" %>
    &lt;%@ page import="java.net.URLConnection" %>
    &lt;%@ page import="java.util.Date" %>
    </xsl:template>

    <!--   Define a Result class to hold the destination, comments, and  HTTP status code that will be set by 'determineResult' method.
    -->
    <xsl:template name="declarations">&lt;%!

        // Handles server side includes so they can be parsed
        private class JSPIncluder
        {
            void readInput(HttpServletRequest request, String strIncludePath) throws JspException
            {
                URLConnection conn;

                // Get URL
                StringBuffer strUrl = request.getRequestURL();
                String strUri = strUrl.toString();
                int nFindSlash = strUri.lastIndexOf("/");
                if (nFindSlash != -1)
                {
                    strUri = strUri.substring(0, nFindSlash + 1);
                }
                strUri += strIncludePath;
                // Open connection
                try
                {
                    conn = (new URL(strUri)).openConnection();
                    conn.setDoInput(true);
                    conn.setDoOutput(false);
                    conn.connect();
                }
                catch (Exception e)
                {
                    throw new JspException(e.toString());
                }

                // Read in contents
                try
                {
                    BufferedReader in = new BufferedReader(new InputStreamReader(conn.getInputStream()));
                    StringBuffer buff = new StringBuffer();
                    char[] chars = new char[2048];
                    int nLen;

                    while ((nLen = in.read(chars, 0, chars.length)) &gt;= 0)
                    {
                        buff.append(chars, 0, nLen);
                    }
                    m_strBuffer = buff.toString();
                    in.close();
                }
                catch (Exception e)
                {
                    throw new JspException(e.toString());
                }
            }

            boolean replace(String strFind, String strReplace)
            {
                boolean bFound = false;
                if (m_strBuffer != null &amp;&amp; m_strBuffer.length() > 0)
                {
                    int a = 0;
                    int b = 0;
                    while (true)
                    {
                        a = m_strBuffer.indexOf(strFind, b);
                        if (a != -1)
                        {
                            m_strBuffer = m_strBuffer.substring(0, a) + strReplace + m_strBuffer.substring(a + strFind.length());
                            b = a + strReplace.length();
                            bFound = true;
                        }
                        else
                        {
                            break;
                        }
                    }
                }
                return bFound;
            }

            void doOutput(PageContext context) throws JspException
            {
                JspWriter out = context.getOut();
                try
                {
                    out.print(m_strBuffer.toString());
                }
                catch (Exception e)
                {
                    throw new JspException(e.toString());
                }
            }
            private String m_strBuffer;
        }

      private class Result {
        String dest;
        long sleep = 0;
        boolean expiresHeaderSet = false;
        long expires = 0;
        boolean include = false;
        StringBuffer comments = new StringBuffer();
        int statusCode = 200;
      }
      private final String NL = System.getProperty("line.separator");
      private void determineResult(HttpServletRequest request, Result result) {
        <xsl:apply-templates />
      }
    %&gt;</xsl:template>

    <!--  Create Result object and call 'determineResult' to set its fields.  Return VoiceXML document only if HTTP response status code is 200.
      Otherwise, return just the status code.
    -->
    <xsl:template name="determineResult" >&lt;%
        Result myResult = new Result();
        determineResult(request, myResult);
        response.setStatus(myResult.statusCode);

        if (myResult.sleep &gt; 0)
        {
            try
            {
                Thread.sleep(myResult.sleep * 1000);
            }
            catch (InterruptedException e)
            {
                throw new JspException(e.toString());
            }
        }

        if (myResult.expiresHeaderSet)
        {
            Date now = new Date();
            long nMillis = now.getTime();
            response.setDateHeader("Expires", nMillis + myResult.expires*1000);
        }

        if (myResult.include)
        {
            Date now = new Date();
            long nMillis = now.getTime();
            String strEpoch = String.valueOf(nMillis);
            JSPIncluder includer = new JSPIncluder();
            includer.readInput(request, myResult.dest);
            includer.replace("__EPOCH__", strEpoch);
            includer.doOutput(pageContext);
        }
        else {%&gt;<xsl:call-template name="vxml" />&lt;%}%&gt;
    </xsl:template>

    <xsl:template match="if-parameter" >
      if (<xsl:call-template name="genIfExpr">
            <xsl:with-param name="type" select="'Parameter'" />
          </xsl:call-template>) {
        <xsl:apply-templates />
      }
    </xsl:template>

    <xsl:template match="if-header" >
      if (<xsl:call-template name="genIfExpr">
            <xsl:with-param name="type" select="'Header'" />
          </xsl:call-template>) {
        <xsl:apply-templates />
      }
    </xsl:template>

    <!--  Generate an expression that determines when the condition of an 'if-*'  element is true.  The 'type' parameter determines the
      HttpServletRequest method to use to get the value to be checked.
    -->
    <xsl:template name="genIfExpr" >
      <xsl:param name="type" />
      <xsl:variable name="method">
        <xsl:choose>
          <xsl:when test="@ignore-case = 'true'" >equalsIgnoreCase</xsl:when>
          <xsl:otherwise>equals</xsl:otherwise>
        </xsl:choose>
      </xsl:variable>
      <xsl:choose>
        <xsl:when test="@value">
          request.get<xsl:value-of select="$type"/>
            ("<xsl:value-of select="@name"/>") != null &amp;&amp;
          request.get<xsl:value-of select="$type"/>
            ("<xsl:value-of select="@name"/>").<xsl:value-of select="$method"/>
            ("<xsl:value-of select="@value" />")
        </xsl:when>
        <xsl:otherwise>
          request.get<xsl:value-of select="$type"/>("<xsl:value-of select="@name"/>") != null
        </xsl:otherwise>
      </xsl:choose>
    </xsl:template>

    <xsl:template match="if-method" >
      if (request.getMethod().equalsIgnoreCase("<xsl:value-of select="@type" />")) {
        <xsl:apply-templates />
      }
    </xsl:template>

    <!--  Disarm double quotes and newline characters from comments, then  add to result's comment buffer for use later in 'log' element.
    -->
    <xsl:template match="comment" >
      result.comments.append
        ("<xsl:value-of select="translate(., '&#034;&#013;&#010;', '   ')" />".trim());
      result.comments.append(NL);
    </xsl:template>

    <xsl:template match="next" >
      <xsl:if test="@code" >
        result.statusCode = <xsl:value-of select="@code" />;
      </xsl:if>
      <xsl:if test="@dest" >
          result.dest = "<xsl:value-of select="@dest" />";
      </xsl:if>
      <xsl:if test="@include = 'true'">
        result.include = true;
      </xsl:if>
      <xsl:if test="@sleep">
          result.sleep = <xsl:value-of select="@sleep" />;
      </xsl:if>
      <xsl:if test="@expires">
          result.expiresHeaderSet = true;
          result.expires = <xsl:value-of select="@expires" />;
      </xsl:if>
        return;
    </xsl:template>

    <!--  Generate VoiceXML document that does a 'goto' to the document  indicated in myResult.  If comment buffer is not empty, include
      a 'log' element to aid in debugging.
    -->
    <xsl:template name="vxml" ><![CDATA[<?xml version="1.0" ?>
    <vxml version="2.0" xmlns="http://www.w3.org/2001/vxml">
      <form>
        <block><% String comments = myResult.comments.toString();
       if (comments.length()>0) {%>
          <log>]]>
            <xsl:text disable-output-escaping="yes">
              &lt;![CDATA[&lt;%= comments %&gt;]]&gt;
            </xsl:text><![CDATA[
          </log><%}%>
          <goto next="<%= myResult.dest %>"/>
        </block>
      </form>
    </vxml> ]]>
    </xsl:template>

    </xsl:stylesheet>

The following XSLT document can be used to transform an IRCGI document to Perl:

    <?xml version="1.0"?>
    <!-- Copyright 1998-2003 W3C (MIT, ERCIM, Keio), All Rights Reserved. See http://www.w3.org/Consortium/Legal/. -->
    <!-- Brought to you by... matto@tellme.com on 10/21/2002 -->
    <xsl:stylesheet version="1.0"
      xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
    <xsl:output method="text"/>

    <xsl:template match="/" >
      <xsl:apply-templates />
    </xsl:template>

    <!-- root document element -->
    <xsl:template match="ircgi">
      <xsl:call-template name="header" />
      <xsl:apply-templates />
      <xsl:call-template name="footer" />
    </xsl:template>

    <!-- handle CGI parameter checks -->
    <xsl:template match="if-parameter" >
      $val = param("<xsl:value-of select="@name"/>");
      <xsl:call-template name="check-value">
        <xsl:with-param name="value" select="@value"/>
        <xsl:with-param name="starts-with" select="@starts-with"/>
        <xsl:with-param name="ignore-case" select="@ignore-case"/>
      </xsl:call-template>
    </xsl:template>

    <!-- handle HTTP Request header checks -->
    <xsl:template match="if-header">
      $val = $ENV{<xsl:call-template name="map-header"><xsl:with-param name="header" select="@name"/></xsl:call-template>};
      <xsl:call-template name="check-value">
        <xsl:with-param name="value" select="@value"/>
        <xsl:with-param name="starts-with" select="@starts-with"/>
        <xsl:with-param name="ignore-case" select="@ignore-case"/>
      </xsl:call-template>
    </xsl:template>

    <!-- in Perl, the Request-Method is just another HTTP Request header -->
    <xsl:template match="if-method">
     $val = $ENV{REQUEST_METHOD};
      <xsl:call-template name="check-value">
        <xsl:with-param name="value">
          <xsl:choose>
            <xsl:when test="@type"><xsl:value-of select="@type"/></xsl:when>
            <xsl:otherwise>get</xsl:otherwise> <!-- default http request method -->
          </xsl:choose>
        </xsl:with-param>
        <xsl:with-param name="ignore-case" select="'true'"/>
      </xsl:call-template>
    </xsl:template>

    <!-- strip comment elements -->
    <xsl:template match="comment">
      push @comments, qq {<xsl:value-of select="."/>};
    </xsl:template>

    <!-- handle next elements -->
    <xsl:template match="next">
        return {
      <xsl:choose>
        <xsl:when test="not(@code) and not(@dest)">
          status => "200",
        </xsl:when>
      <xsl:otherwise>
        <xsl:if test="@dest">
          next => "<xsl:value-of select="@dest" />",
          <xsl:if test="@include = 'true'">
            include => 1,
          </xsl:if>
        </xsl:if>
        <xsl:if test="@code">
          status => "<xsl:value-of select="@code" />",
        </xsl:if>
      </xsl:otherwise>
      </xsl:choose>
      <xsl:if test="@sleep">
        sleep => "<xsl:value-of select="@sleep"/>",
      </xsl:if>
      <xsl:if test="@expires">
        expires => int(<xsl:value-of select="@expires"/>),
      </xsl:if>
        comments => \@comments};
    </xsl:template>

    <!-- check the value, if any, and continue processing child elements -->
    <xsl:template name="check-value">
    <xsl:param name="value"/>
    <xsl:param name="starts-with"/>
    <xsl:param name="ignore-case"/>
    <xsl:choose>
    <xsl:when test="$starts-with">
      my $starts = '<xsl:value-of select="$starts-with"/>';
      if (defined($val) &amp;&amp; ($val =~ /^$starts/<xsl:if test="$ignore-case='true'">i</xsl:if>)) {
        <xsl:apply-templates/>
      }
    </xsl:when>
    <xsl:when test="$value=''">
      if (defined($val) &amp;&amp; ($val =~ /^\s*$/)) {
        <xsl:apply-templates/>
      }
    </xsl:when>
    <xsl:when test="$value">
      my $match = '<xsl:value-of select="$value"/>';
      if (defined($val) &amp;&amp; ($val =~ /^$match$/<xsl:if test="$ignore-case='true'">i</xsl:if>)) {
        <xsl:apply-templates/>
      }
    </xsl:when>
    <xsl:otherwise>
      if (defined($val)) {
        <xsl:apply-templates/>
      }
    </xsl:otherwise>
    </xsl:choose>
    </xsl:template>

    <xsl:template name="header">#!/usr/local/bin/perl -w
    use strict;
    use CGI qw(param);
    use CGI::Util qw(expires);

    # limit sleep time to 1 minute to prevent DOS attack
    use constant SLEEP_LIMIT => 60;

    # forward decls
    sub GetStatusText;
    sub Run;
    sub JumpTo;
    sub GetContentType;

    my $rhRetval = Run();
    my $next = $rhRetval->{next}; # where to Mr. Magoo?
    my $statusCode = $rhRetval->{status};
    my $statusText = "unknown status";
    my $ctype = GetContentType($next);
    my $raComments = $rhRetval->{comments};
    my $bInclude = $rhRetval->{include};
    my $expires_delta = $rhRetval->{expires};
    my $epoch = time;

    if (defined($next) &amp;&amp; defined($bInclude) &amp;&amp; 1 == $bInclude)
    {
      # restrict paths when allowing source inclusion
      if (($next =~ /^\//) || ($next =~ /\/\.\./))
      {
        $statusCode = 403;
      }
    }

    my $sleep = $rhRetval->{sleep};
    if (defined($sleep))
    {
      if (($sleep =~ /^\d+$/) &amp;&amp; ($sleep &lt;= SLEEP_LIMIT))
      {
        sleep $sleep;
      }
      else
      {
        push @$raComments, "Bad sleep interval $sleep";
      }
    }

    print "Content-Type: $ctype\n";
    if (defined($expires_delta))
    {
      print ExpiresFromDelta($expires_delta) . "\n";
    }
    if(defined($statusCode))
    {
      $statusText = GetStatusText($statusCode);
      print "Status: $statusCode $statusText\n\n";
    }
    else
    {
      print "\n";
    }

    if (!defined($next))
    {
      print "$statusText\n";
    }
    else
    {
      my $content;
      if ($bInclude)
      {
        $! = 0; # clear i/o errs
        open HINCLUDE, $next;
        if ($! != 0)
        {
          push @$raComments, "Unable to open $next";
          $content = JumpTo($next, $raComments);
          print STDERR "Unable to open $next\n";
        }
    	else
    	{
    	  my $eor = $/;
    	  undef $/;
    	  $content = &lt;HINCLUDE&gt;;
    	  # allow caching tests to be performed by interpolating __EPOCH__
    	  $content =~ s/__EPOCH__/$epoch/g;
    	  close HINCLUDE;
    	  $/ = $eor;
    	}
      }
      else
      {
        $content = JumpTo($next, $raComments);
      }

      print $content;
    }

    # Return a simple VoiceXML document that navigates
    #   to the URI specified by $next
    # Dump the comments in the array $raComments to the call log
    sub JumpTo
    {
      my($next, $raComments) = @_;

    <![CDATA[
      my $content = <<EOF;
    <?xml version="1.0"?>
    <vxml version="2.0"
      xmlns="http://www.w3.org/2001/vxml"
    >
    <form>
      <block>
    EOF
    ]]>
    foreach my $comment (@$raComments)
    {
      $content .= qq{&lt;log>$comment &lt;/log>\n};
    }
    <![CDATA[
    $content .= <<EOF;
        <goto next="$next"/>
      </block>
    </form>
    </vxml>
    EOF
    ]]>

      $content;
    }

    # Determine what to do next
    # Return a hash containing one or more of the following keys:
    #   next - the next document to navigate to
    #   code - the HTTP response code
    #   comments - a reference to an array of comments to aid in debugging
    sub Run
    {
      my $val; # temp var to stash param or header value
      my @comments = (); # array of comments obtained while processing
    </xsl:template>

    <xsl:template name="footer" >
    }

    # Map a status code to an informative string
    # http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html#sec6.1.1
    sub GetStatusText
    {
      my($code) = @_;

      my $rhCodes = {100 => "Continue",
      101 => "Switching Protocols",
      200 => "OK",
      201 => "Created",
      202 => "Accepted",
      203 => "Non-Authoritative Information",
      204 => "No Content",
      205 => "Reset Content",
      206 => "Partial Content",
      300 => "Multiple Choices",
      301 => "Moved Permanently",
      302 => "Found",
      303 => "See Other",
      304 => "Not Modified",
      305 => "Use Proxy",
      307 => "Temporary Redirect",
      400 => "Bad Request",
      401 => "Unauthorized",
      402 => "Payment Required",
      403 => "Forbidden",
      404 => "Not Found",
      405 => "Method Not Allowed",
      406 => "Not Acceptable",
      407 => "Proxy Authentication Required",
      408 => "Request Time-out",
      409 => "Conflict",
      410 => "Gone",
      411 => "Length Required",
      412 => "Precondition Failed",
      413 => "Request Entity Too Large",
      414 => "Request-URI Too Large",
      415 => "Unsupported Media Type",
      416 => "Requested range not satisfiable",
      417 => "Expectation Failed",
      500 => "Internal Server Error",
      501 => "Not Implemented",
      502 => "Bad Gateway",
      503 => "Service Unavailable",
      504 => "Gateway Time-out",
      505 => "HTTP Version not supported extension-code"};

      return (exists($rhCodes->{$code}) ? $rhCodes->{$code} : "invalid status code");
    }

    sub GetContentType
    {
      my($next) = @_;

      my $ctype = "text/plain";
      if (defined($next))
      {
        my $rhTypes = {'txml' => 'text/xml', 'vxml' => 'text/xml',
          'xml' => 'text/xml', 'srgs' => 'text/xml'};
        my @parts = split /\./, $next;
        my $ext = $parts[0];
        if (exists($rhTypes->{$ext}))
        {
          $ctype = $rhTypes->{$ext};
        }
      }

      $ctype;
    }

    # return an expires header given seconds since epoch
    sub ExpiresFromDelta
    {
      my($delta) = @_;
      $delta = (($delta >= 0 &amp;&amp; $delta !~ /^\+/) ? "+" : "") . $delta . "s";
      "Expires: " . expires($delta);
    }
    </xsl:template>

    <!--   the headers we're willing to expose.
      allowing arbitrary header requests is a security risk
    -->
    <xsl:template name="map-header">
    <xsl:param name="header"/>
    <xsl:choose>
      <xsl:when test="$header = 'User-Agent'">HTTP_USER_AGENT</xsl:when>
      <xsl:when test="$header = 'Request-Method'">REQUEST_METHOD</xsl:when>
      <xsl:when test="$header = 'Content-Type'">CONTENT_TYPE</xsl:when>
      <xsl:otherwise>__UNKNOWN__<xsl:value-of select="$header"/></xsl:otherwise>
    </xsl:choose>
    </xsl:template>

    </xsl:stylesheet>

### B.8 Test developer requirements

The directory convention requires test developers to ensure that paths from and to other test documents follow the convention.

The following example contains a reference to an IRCGI document from a VoiceXML document:

    <goto next="cgi-bin/ua.ircgi" />

The following example contains a reference to a VoiceXML document from an IRCGI document:

    <next dest="../pass.vxml"/>

### B.9 Web server administrator requirements

Given the directory convention, Web server administrators must do the following:

- Allow CGI execution within the "cgi-bin" directory below each assertion directory.
- Associate the ".ircgi" suffix with the preferred server-side script engine.

The following example configures Apache to execute documents with a .ircgi extension as a Perl CGI:

    Addhandler cgi-script .ircgi

The following example configures Tomcat to run transformed files with a .ircgi extension as a JSP:

    <servlet-mapping>
      <servlet-name>jsp</servlet-name>
      <url-pattern>*.ircgi</url-pattern>
    </servlet-mapping>

## Appendix C - Acknowledgements

The VoiceXML 2.0 Implementation Report includes 610 assertions and corresponding tests. The Voice Browser Working Group would like to further acknowledge the contributions of several individuals:

- Jerry Carter, Dan Evans, Jim Ferrans, Will Gardella, and Jeff Kusnitz for leading sub-teams through the arduous process of authoring and reviewing assertions and tests.
- Brad Porter and Scott McGlashan for coordinating the overall effort.
- Matt Oshry for building and maintaining a Web and voice site on Tellme Networks infrastructure that allowed contributors to manage and execute the assertions and tests.
- Jerry Carter and Matt Oshry for contributing the test markup API.
- Pete Danielsen and Matt Oshry for contributing the server-side test markup (IRCGI) API.