Voice Extensible Markup Language (VoiceXML) Version

The text inserted by the element is not subject to any special interpretation; in particular, it is not parsed as an [SSML] document or document fragment. XML special characters (&, >, and <) are not treated specially and do not need to be escaped. The equivalent effect may be obtained by literally inserting the text computed by the element in a CDATA section. For example, when the following variable assignment:

is referenced in a prompt element as

The price of is $1.

the following output is produced.

The price of AT&T is $1.

4.1.5 Bargein

If an implementation platform supports bargein, the application author can specify whether a user can interrupt, or "bargein" on, a prompt using speech or DTMF input. This speeds up conversations, but is not always desired. If the application author requires that the user must hear all of a warning, legal notice, or advertisement, bargein should be disabled. This is done with the bargein attribute:

Users can interrupt a prompt whose bargein attribute is true, but must wait for completion of a prompt whose bargein attribute is false. In the case where several prompts are queued, the bargein attribute of each prompt is honored during the period of time in which that prompt is playing. If bargein occurs during any prompt in a sequence, all subsequent prompts are not played (even those whose bargein attribute is set to false). If the bargein attribute is not specified, then the value of the bargein property is used if set.

When the bargein attribute is false, input is not buffered while the prompt is playing, and any DTMF input buffered in a transition state is deleted from the buffer (Section 4.1.8 describes input collection during transition states).

Note that not all speech recognition engines or implementation platforms support bargein. For a platform to support bargein, it must support at least one of the bargein types described in Section 4.1.5.1.

4.1.5.1 Bargein type

When bargein is enabled, the bargeintype attribute can be used to suggest the type of bargein the platform will perform in response to voice or DTMF input. Possible values for this attribute are:

Table 39: bargeintype Values

If the bargeintype attribute is not specified, then the value of the bargeintype property is used. Implementations that claim to support bargein are required to support at least one of these two types. Mixing these types within a single queue of prompts can result in unpredictable behavior and is discouraged.

In the case of "speech" bargeintype, the exact meaning of "speech input" is necessarily implementation-dependent, due to the complexity of speech recognition technology. It is expected that the prompt will be stopped as soon as the platform is able to reliably determine that the input is speech. Stopping the prompt as early as possible is desireable because it avoids the "stutter" effect in which a user stops in mid-utterance and re-starts if he does not believe that the system has heard him.

4.1.6 Prompt Selection

Tapered prompts are those that may change with each attempt. Information-requesting prompts may become more terse under the assumption that the user is becoming more familiar with the task. Help messages become more detailed perhaps, under the assumption that the user needs more help. Or, prompts can change just to make the interaction more interesting.

Each input item, , and menu has an internal prompt counter that is reset to one each time the form or menu is entered. Whenever the system selects a given input item in the select phase of FIA and FIA does perform normal selection and queuing of prompts (i.e., as described in Section 5.3.6, the previous iteration of FIA did not end with a catch handler that had no reprompt), the input item's associated prompt counter is incremented. This is the mechanism supporting tapered prompts.

For instance, here is a form with a form level prompt and field level prompts:

A conversation using this form follows:

C: Welcome to the ice cream survey.

C: What is your favorite flavor? (the "flavor" field's prompt counter is 1)

H: Pecan praline.

C: I do not understand.

C: What is your favorite flavor? (the prompt counter is now 2)

H: Pecan praline.

C: I do not understand.

C: Say chocolate, vanilla, or strawberry. (prompt counter is 3)

H: What if I hate those?

C: I do not understand.

C: Say chocolate, vanilla, or strawberry. (prompt counter is 4)

H: ...

This is just an example to illustrate the use of prompt counters. A polished form would need to offer a more extensive range of choices and to deal with out of range values in more flexible way.

When it is time to select a prompt, the prompt counter is examined. The child prompt with the highest count attribute less than or equal to the prompt counter is used. If a prompt has no count attribute, a count of "1" is assumed.

A conditional prompt is one that is spoken only if its condition is satisfied. In this example, a prompt is varied on each visit to the enclosing form.

When a prompt must be chosen, a set of prompts to be queued is chosen according to the following algorithm:

1. Form an ordered list of prompts consisting of all prompts in the enclosing element in document order.
2. Remove from this list all prompts whose cond evaluates to false after conversion to boolean.
3. Find the "correct count": the highest count among the prompt elements still on the list less than or equal to the current count value.
4. Remove from the list all the elements that don't have the "correct count".

All elements that remain on the list will be queued for play.

4.1.7 Timeout

The timeout attribute specifies the interval of silence allowed while waiting for user input after the end of the last prompt. If this interval is exceeded, the platform will throw a noinput event. This attribute defaults to the value specified by the timeout property (see Section 6.3.4) at the time the prompt is queued. In other words, each prompt has its own timeout value.

The reason for allowing timeouts to be specified as prompt attributes is to support tapered timeouts. For example, the user may be given five seconds for the first input attempt, and ten seconds on the next.

The prompt timeout attribute determines the noinput timeout for the following input:

If several prompts are queued before a field input, the timeout of the last prompt is used.

4.1.8 Prompt Queueing and Input Collection

A VoiceXML interpreter is at all times in one of two states:

• waiting for input in an input item (such as , , or ),or
• transitioning between input items in response to an input (including spoken utterances, dtmf key presses, and input-related events such as a noinput or nomatch event) received while in the waiting state. While in the transitioning state no speech input is collected, accepted or interpreted. Consequently root and document level speech grammars (such as defined in s) may not be active at all times. However, DTMF input (including timing information) should be collected and buffered in the transition state. Similarly, asynchronously generated events not related directly to execution of the transition should also be buffered until the waiting state (e.g. connection.disconnect.hangup).

The waiting and transitioning states are related to the phases of the Form Interpretation Algorithm as follows:

• the waiting state is eventually entered in the collect phase of an input item (at the point at which the interpreter waits for input), and
• the transitioning state encompasses the process and select phases, the collect phase for control items (such as s), and the collect phase for input items up until the point at which the interpreter waits for input.

This distinction of states is made in order to greatly simplify the programming model. In particular, an important consequence of this model is that the VoiceXML application designer can rely on all executable content (such as the content of and elements) being run to completion, because it is executed while in the transitioning state, which may not be interrupted by input.

While in the transitioning state various prompts are queued, either by the element in executable content or by the element in form items. In addition, audio may be queued by the fetchaudio attribute. The queued prompts and audio are played either

• when the interpreter reaches the waiting state, at which point the prompts are played and the interpreter listens for input that matches one of the active grammars, or
• when the interpreter begins fetching a resource (such as a document) for which fetchaudio was specified. In this case the prompts queued before the fetchaudio are played to completion, and then, if the resource actually needs to be fetched (i.e. it is not unexpired in the cache), the fetchaudio is played until the fetch completes. The interpreter remains in the transitioning state and no input is accepted during the fetch.

Note that when a prompt's bargein attribute is false, input is not collected and DTMF input buffered in a transition state is deleted (see Section 4.1.5).

When an ASR grammar is matched, if DTMF input was consumed by a simultaneously active DTMF grammar (but did not result in a complete match of the DTMF grammar), the DTMF input may, at processor discretion, be discarded.

Before the interpreter exits all queued prompts are played to completion. The interpreter remains in the transitioning state and no input is accepted while the interpreter is exiting.

It is a permissible optimization to begin playing prompts queued during the transitioning state before reaching the waiting state, provided that correct semantics are maintained regarding processing of the input audio received while the prompts are playing, for example with respect to bargein and grammar processing.

The following examples illustrate the operation of these rules in some common cases.

Case 1

Typical non-fetching case: field, followed by executable content (such as and ), followed by another field.

in document d0

<field name="f0"/>

<block>
    executable content e1
    queues prompts {p1}
</block>

<field name="f2">
    queues prompts {p2}
    enables grammars {g2}
</field>

As a result of input received while waiting in field f0 the following actions take place:

• in transitioning state
  • execute e1 (without goto)
  • queue prompts {p1}
  • queue prompts {p2}
• in waiting state, simultaneously
  • play prompts {p1,p2}
  • enable grammars {g2} and wait for input

Case 2

Typical fetching case: field, followed by executable content (such as and ) ending with a that specifies fetchaudio, ending up in a field in a different document that is fetched from a server.

in document d0

<field name="f0"/>

<block>
    executable content e1
    queues prompts {p1}
    ends with goto f2 in d1 with fetchaudio fa
</block>

in document d1

<field name="f2">
    queues prompts {p2}
    enables grammars {g2}
</field>

As a result of input received while waiting in field f0 the following actions take place:

• in transitioning state
  • execute e1
  • queue prompts {p1}
  • simultaneously
    * fetch d1
    * play prompts {p1} to completion and then play fa until fetch completes
  • queue prompts {p2}
• in waiting state, simultaneously
  • play prompts {p2}
  • enable grammars {g2} and wait for input

Case 3

As in Case 2, but no fetchaudio is specified.

in document d0

<field name="f0"/>

<block>
    executable content e1
    queues prompts {p1}
    ends with goto f2 in d1 (no fetchaudio specified)
</block>

in document d1

<field name="f2">
    queues prompts {p2}
    enables grammars {g2}
</field>

As a result of input received while waiting in field f0 the following actions take place:

• in transitioning state
  • execute e1
  • queue prompts {p1}
  • fetch d1
  • queue prompts {p2}
• in waiting state, simultaneously
  • play prompts {p1, p2}
  • enable grammars {g2} and wait for input

5. Control flow and scripting

5.1 Variables and Expressions

VoiceXML variables are in all respects equivalent to ECMAScript variables: they are part of the same variable space. VoiceXML variables can be used in a

A The time is hours, minutes, and seconds. Do you want to hear another time?

The content of a

All variables must be declared before being referenced by ECMAScript scripts, or by VoiceXML elements as described in Section 5.1.1.

5.3.13 log element

The element allows an application to generate a logging or debug message which a developer can use to help in application development or post-execution analysis of application performance.

The element may contain any combination of text (CDATA) and elements. The generated message consists of the concatenation of the text and the string form of the value of the "expr" attribute of the elements.

The manner in which the message is displayed or logged is platform-dependent. The usage of label is platform-dependent. Platforms are not required to preserve white space.

ECMAScript expressions in must be evaluated in document order. The use of the element should have no other side-effects on interpretation.

The card number was

The element has the following attributes:

Table 53: Attributes

6. Environment and Resources

6.1 Resource Fetching

6.1.1 Fetching

A VoiceXML interpreter context needs to fetch VoiceXML documents, and other resources, such as audio files, grammars, scripts, and objects. Each fetch of the content associated with a URI is governed by the following attributes:

Table 54: Fetch Attributes

When content is fetched from a URI, the fetchtimeout attribute determines how long to wait for the content (starting from the time when the resource is needed), and the fetchhint attribute determines when the content is fetched. The caching policy for a VoiceXML interpreter context utilizes the maxage and maxstale attributes and is explained in more detail below.

The fetchhint attribute, in combination with the various fetchhint properties, is merely a hint to the interpreter context about when it may schedule the fetch of a resource. Telling the interpreter context that it may prefetch a resource does not require that the resource be prefetched; it only suggests that the resource may be prefetched. However, the interpreter context is always required to honor the safe fetchhint.

When transitioning from one dialog to another, through either a , , , , or element, there are additional rules that affect interpreter behavior. If the referenced URI names a document (e.g. "doc#dialog"), or if query data is provided (through POST or GET), then a new document is obtained (either from a local cache, intermediate cache, or from a origin Web server). When it is obtained, the document goes through its initialization phase (i.e., obtaining and initializing a new application root document if needed, initializing document variables, and executing document scripts). The requested dialog (or first dialog if none is specified) is then initialized and execution of the dialog begins.

Generally, if a URI reference contains only a fragment (e.g., "#my_dialog"), then no document is fetched, and no initialization of that document is performed. However, always results in a fetch, and if a fragment is accompanied by a namelist attribute there will also be a fetch.

Another exception is when a URI reference in a leaf document references the application root document. In this case, the root document is transitioned to without fetching and without initialization even if the URI reference contains an absolute or relative URI (see Section 1.5.2 and [RFC2396]). However, if the URI reference to the root document contains a query string or a namelist attribute, the root document is fetched.

Elements that fetch VoiceXML documents also support the following additional attribute:

Table 55: Additional Fetch Attribute

The fetchaudio attribute is useful for enhancing a user experience when there may be noticeable delays while the next document is retrieved. This can be used to play background music, or a series of announcements. When the document is retrieved, the audio file is interrupted if it is still playing. If an error occurs retrieving fetchaudio from its URI, no badfetch event is thrown and no audio is played during the fetch.

6.1.2 Caching

The VoiceXML interpreter context, like [HTML] visual browsers, can use caching to improve performance in fetching documents and other resources; audio recordings (which can be quite large) are as common to VoiceXML documents as images are to HTML pages. In a visual browser it is common to include end user controls to update or refresh content that is perceived to be stale. This is not the case for the VoiceXML interpreter context, since it lacks equivalent end user controls. Thus enforcement of cache refresh is at the discretion of the document through appropriate use of the maxage, and maxstale attributes.

The caching policy used by the VoiceXML interpreter context must adhere to the cache correctness rules of HTTP 1.1 ([RFC2616]). In particular, the Expires and Cache-Control headers must be honored. The following algorithm summarizes these rules and represents the interpreter context behavior when requesting a resource:

• If the resource is not present in the cache, fetch it from the server using get.
• If the resource is in the cache,
  • If a maxage value is provided,
    * If age of the cached resource <= maxage,
    * If the resource has expired,
    * Perform maxstale check.
    * Otherwise, use the cached copy.
    * Otherwise, fetch it from the server using get.
  • Otherwise,
    * If the resource has expired,
    * Perform maxstale check.
    * Otherwise, use the cached copy.

The "maxstale check" is:

• If maxstale is provided,
  • If cached copy has exceeded its expiration time by no more than maxstale seconds, then use the cached copy.
  • Otherwise, fetch it from the server using get.
• Otherwise, fetch it from the server using get.

Note: it is an optimization to perform a "get if modified" on a document still present in the cache when the policy requires a fetch from the server.

The maxage and maxstale properties are allowed to have no default value whatsoever. If the value is not provided by the document author, and the platform does not provide a default value, then the value is undefined and the 'Otherwise' clause of the algorithm applies. All other properties must provide a default value (either as given by the specification or by the platform).

While the maxage and maxstale attributes are drawn from and directly supported by HTTP 1.1, some resources may be addressed by URIs that name protocols other than HTTP. If the protocol does not support the notion of resource age, the interpreter context shall compute a resource's age from the time it was received. If the protocol does not support the notion of resource staleness, the interpreter context shall consider the resource to have expired immediately upon receipt.

6.1.2.1 Controlling the Caching Policy

VoiceXML allows the author to override the default caching behavior for each use of each resource (except for any document referenced by the element's application attribute: there is no markup mechanism to control the caching policy for an application root document).

Each resource-related element may specify maxage and maxstale attributes. Setting maxage to a non-zero value can be used to get a fresh copy of a resource that may not have yet expired in the cache. A fresh copy can be unconditionally requested by setting maxage to zero.

Using maxstale enables the author to state that an expired copy of a resource, that is not too stale (according to the rules of HTTP 1.1), may be used. This can improve performance by eliminating a fetch that would otherwise be required to get a fresh copy. It is especially useful for authors who may not have direct server-side control of the expiration dates of large static files.

6.1.3 Prefetching

Prefetching is an optional feature that an interpreter context may implement to obtain a resource before it is needed. A resource that may be prefetched is identified by an element whose fetchhint attribute equals "prefetch". When an interpreter context does prefetch a resource, it must ensure that the resource fetched is precisely the one needed. In particular, if 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. Likewise, the fetch for a must not be moved prior to any assignments of the namelist variables.

The expiration status of a resource must be checked on each use of the resource, and, if its fetchhint attribute is "prefetch", then it is prefetched. The check must follow the caching policy specified in Section 6.1.2.

6.1.4 Protocols

The "http" URI scheme must be supported by VoiceXML platforms, the "https" protocol should be supported and other URI protocols may be supported.

6.2 Metadata Information

Metadata information is information about the document rather than the document's content. VoiceXML 2.0 provides two elements in which metadata information can be expressed: and . The element provides more general and powerful treatment of metadata information than .

VoiceXML does not specify required metadata information. However, it does recommend that metadata is expressed using the element with information in Resource Description Framework (RDF) [RDF-SYNTAX] using the Dublin Core version 1.0 RDF schema [DC] (see Section 6.2.2).

6.2.1 meta element

The element specifies meta information as in [HTML]. There are two types of .

The first type specifies a metadata property of the document as a whole and is expressed by the pair of attributes, name and content. For example to specify the maintainer of a VoiceXML document:

Hello

The second type of specifies HTTP response headers and is expressed by the pair of attributes http-equiv and content. In the following example, the first element sets an expiration date that prevents caching of the document; the second element sets the Date header.

Hello

Attributes of are:

Table 56: Attributes

Exactly one of "name" or "http-equiv" must be specified; otherwise, an error.badfetch event is thrown.

6.2.2 metadata element

The element is container in which information about the document can be placed using a metadata schema. Although any metadata schema can be used with , it is recommended that the RDF schema is used in conjunction with metadata properties defined in the Dublin Core Metadata Initiative.

RDF is a declarative language and provides a standard way for using XML to represent metadata in the form of statements about properties and relationships of items on the Web. Content creators should refer to W3C metadata Recommendations [RDF-SYNTAX] and [RDF-SCHEMA] as well as the Dublin Core Metadata Initiative [DC], which is a set of generally applicable core metadata properties (e.g., Title, Creator, Subject, Description, Copyrights, etc.).

The following Dublin Core metadata properties are recommended in :

Table 57: Recommended Dublin Core Metadata Properties

Here is an example of how can be included in a VoiceXML document using the Dublin Core version 1.0 RDF schema[DC]:

<rdf:RDF xmlns:rdf = "http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdfs = "http://www.w3.org/TR/1999/PR-rdf-schema-19990303#" xmlns:dc = "" title="undefined" rel="noopener noreferrer">http://purl.org/metadata/dublin_core#">

<rdf:Description about="http://www.example.com/meta.vxml" dc:Title="Directory Enquiry Service" dc:Description="Directory Enquiry Service for London in VoiceXML" dc:Publisher="W3C" dc:Language="en" dc:Date="2002-02-12" dc:Rights="Copyright 2002 John Smith" dc:Format="application/voicexml+xml" >
dc:Creator <rdf:Seq ID="CreatorsAlphabeticalBySurname"> rdf:liJackie Crystal rdf:liWilliam Lee

6.3 property element

The element sets a property value. Properties are used to set values that affect platform behavior, such as the recognition process, timeouts, caching policy, etc.

Properties may be defined for the whole application, for the whole document at the level, for a particular dialog at the or level, or for a particular form item. Properties apply to their parent element and all the descendants of the parent. A property at a lower level overrides a property at a higher level. When different values for a property are specified at the same level, the last one in document order applies. Properties specified in the application root document provide default values for properties in every document in the application; properties specified in an individual document override property values specified in the application root document.

If a platform detects that the value of a property is invalid, then it should throw an error.semantic.

In some cases, elements specify default values for element attributes, such as timeout or bargein. For example, to turn off bargein by default for all the prompts in a particular form:

The element has the following attributes:

Table 58: Attributes

6.3.1 Platform-Specific Properties

An interpreter context is free to provide platform-specific properties. For example, to set the "multiplication factor" for this platform in the scope of this document:

By definition, platform-specific properties introduce incompatibilities which reduce application portability. To minimize them, the following interpreter context guidelines are strongly recommended:

• Platform-specific properties should use reverse domain names to eliminate potential collisions as in: com.example.foo, which is clearly different from net.example.foo
• An interpreter context must not throw an error.unsupported.property event when encountering a property it cannot process; rather the interpreter context must just ignore that property.

6.3.2 Generic Speech Recognizer Properties

The generic speech recognizer properties mostly are taken from the Java Speech API [JSAPI]:

Table 59: Generic Speech Recognizer Properties

6.3.3 Generic DTMF Recognizer Properties

Several generic properties pertain to DTMF grammar recognition:

Table 60: Generic DTMF Recognizer Properties

6.3.4 Prompt and Collect Properties

These properties apply to the fundamental platform prompt and collect cycle:

Table 61: Prompt and Collect Properties

6.3.5 Fetching Properties

These properties pertain to the fetching of new documents and resources (note that maxage and maxstale properties may have no default value - see Section 6.1.2):

Table 62: Fetching Properties

6.3.6 Miscellaneous Properties

Table 63: Miscellaneous Properties

Our last example shows several of these properties used at multiple levels.

6.4 param element

The element is used to specify values that are passed to subdialogs or objects. It is modeled on the [HTML] element. Its attributes are:

Table 64: Attributes

Exactly one of "expr" or "value" must be specified; otherwise, an error.badfetch event is thrown.

The use of valuetype and type is optional in general, although they may be required by specific objects. When is contained in a element, the values specified by it are used to initialize dialog elements in the subdialog that is invoked. See Section 2.3.4 for details regarding initialization of variables in subdialogs using . When is contained in an , the use of the parameter data is specific to the object that is being invoked, and is outside the scope of the VoiceXML specification.

Below is an example of used as part of an . In this case, the first two elements have expressions (implicitly of valuetype="data"), the third has an explicit value, and the fourth is a URI that returns a media type of text/plain. The meaning of this data is specific to the object.

The next example illustrates used with . In this case, two expressions are used to initialize variables in the scope of the subdialog form.

Form with calling dialog

Subdialog in http://another.example.com

Using in a is a convenient way of passing data to a subdialog without requiring the use of server side scripting.

6.5 Value Designations

Several VoiceXML parameter values follow the conventions used in the W3C's Cascading Style Sheet Recommendation [CSS2].

6.5.1 Integers and Real Numbers

Real numbers and integers are specified in decimal notation only. An integer consists of one or more digits "0" to "9". A real number may be an integer, or it may be zero or more digits followed by a dot (.) followed by one or more digits. Both integers and real numbers may be preceded by a "-" or "+" to indicate the sign.

6.5.2 Times

Time designations consist of a non-negative real number followed by a time unit identifier. The time unit identifiers are:

• ms: milliseconds
• s: seconds

Examples include: "3s", "850ms", "0.7s", ".5s" and "+1.5s".

Appendices

Appendix A — Glossary of Terms

active grammar

A speech or DTMF grammar that is currently active. This is based on the currently executing element, and the scope elements of the currently defined grammars.

application

A collection of VoiceXML documents that are tagged with the same application name attribute.

ASR

Automatic speech recognition.

author

The creator of a VoiceXML document.

catch element

A block or one of its abbreviated forms. Certain default catch elements are defined by the VoiceXML interpreter.

control item

A form item whose purpose is either to contain a block of procedural logics () or to allow initial prompts for a mixed initiative dialog ().

CSS W3C Cascading Style Sheet specification.

See [CSS2]

dialog

An interaction with the user specified in a VoiceXML document. Types of dialogs include forms and_menus_.

DTMF (Dual Tone Multi-Frequency)

Touch-tone or push-button dialing. Pushing a button on a telephone keypad generates a sound that is a combination of two tones, one high frequency and the other low frequency.

ECMAScript

A standard version of JavaScript backed by the European Computer Manufacturer's Association. See [ECMASCRIPT]

event

A notification "thrown" by the implementation platform, VoiceXML interpreter context, VoiceXML interpreter, or VoiceXML code. Events include exceptional conditions (semantic errors), normal errors (user did not say something recognizable), normal events (user wants to exit), and user defined events.

executable content

Procedural logic that occurs in , , and event handlers.

form

A dialog that interacts with the user in a highly flexible fashion with the computer and the _user_sharing the initiative.

FIA (Form Interpretation Algorithm)

An algorithm implemented in a _VoiceXML interpreter_which drives the interaction between the user and a VoiceXML form or menu. See Section 2.1.6and Appendix C.

form item

An element of

form item variable

A variable, either implicitly or explicitly defined, associated with each form item in a form. If the form item variable is undefined, the form interpretation algorithm will visit the form item and use it to interact with the user.

implementation platform

A computer with the requisite software and/or hardware to support the types of interaction defined by VoiceXML.

input item

A form item whose purpose is to input a input item variable. Input items include , , , , and .

language identifier

A language identifier labels information content as being of a particular human language variant. Following the XML specification for language identification [XML], a legal language identifier is identified by an RFC 3066 [RFC3066]code. A language code is required by RFC 3066. A country code or other subtag identifier is optional by RFC 3066.

link

A set of grammars that when matched by something the_user_ says or keys in, either transitions to a new dialog or document or throws an event in the current form item.

menu

A dialog presenting the user with a set of choices and takes action on the selected one.

mixed initiative

A computer-human interaction in which either the computer or the human can take initiative and decide what to do next.

JSGF

Java API Speech Grammar Format. A proposed standard for representing speech grammars. See [JSGF]

object

A platform-specific capability with an interface available via VoiceXML.

request

A collection of data including: a URI specifying a document server for the data, a set of name-value pairs of data to be processed (optional), and a method of submission for processing (optional).

script

A fragment of logic written in a client-side scripting language, especially ECMAScript, which is a scripting language that must be supported by any VoiceXML interpreter.

session

A connection between a user and an implementation platform, e.g. a telephone call to a voice response system. One session may involve the interpretation of more than one_VoiceXML document_.

SRGS (Speech Recognition Grammar Specification)

A standard format for context-free speech recognition grammars being developed by the W3C Voice Browser group. Both ABNF and XML formats are defined [SRGS].

SSML (Speech Synthesis Markup Language)

A standard format for speech synthesis being developed by the W3C Voice Browser group [SSML].

subdialog

A VoiceXML dialog (or document) invoked from the current_dialog_ in a manner analogous to function calls.

tapered prompts

A set of prompts used to vary a message given to the human. Prompts may be tapered to be more terse with use (field prompting), or more explicit (help prompts).

throw

An element that fires an event.

TTS

text-to-speech; speech synthesis.

user

A person whose interaction with an implementation platform is controlled by a VoiceXML interpreter.

URI

Uniform Resource Indicator.

URL

Uniform Resource Locator.

VoiceXML document

An XML document conforming to the VoiceXML specification.

VoiceXML interpreter

A computer program that interprets a _VoiceXML document_to control an implementation platform for the purpose of conducting an interaction with a user.

VoiceXML interpreter context

A computer program that uses a VoiceXML interpreter to interpret a VoiceXML Document and that may also interact with the implementation platform independently of the_VoiceXML interpreter_.

W3C

World Wide Web Consortium http://www.w3.org/

Appendix B — VoiceXML Document Type Definition

The VoiceXML DTD is located at http://www.w3.org/TR/voicexml20/vxml.dtd.

Due to DTD limitations, the VoiceXML DTD does not correctly express that the element can contain elements from other XML namespaces.

Note: the VoiceXML DTD includes modified elements from the DTDs of the Speech Recognition Grammar Specification 1.0 [SRGS] and the Speech Synthesis Markup Language 1.0 [SSML].

Appendix C — Form Interpretation Algorithm

The form interpretation algorithm (FIA) drives the interaction between the user and a VoiceXML form or menu. A menu can be viewed as a form containing a single field whose grammar and whose action are constructed from the elements.

The FIA must handle:

• Form initialization.
• Prompting, including the management of the prompt counters needed for prompt tapering.
• Grammar activation and deactivation at the form and form item levels.
• Entering the form with an utterance that matched one of the form's document-scoped grammars while the user was visiting a different form or menu.
• Leaving the form because the user matched another form, menu, or link's document-scoped grammar.
• Processing multiple field fills from one utterance, including the execution of the relevant actions.
• Selecting the next form item to visit, and then processing that form item.
• Choosing the correct catch element to handle any events thrown while processing a form item.

First we define some terms and data structures used in the form interpretation algorithm:

active grammar set

The set of grammars active during a VoiceXML interpreter context's input collection operation.

utterance

A summary of what the user said or keyed in, including the specific grammar matched, and a semantic result consisting of an interpretation structure or, where there is no semantic interpretation, the raw text of the input (see Section 3.1.6). An example utterance might be: "grammar 123 was matched, and the semantic interpretation is {drink: "coke" pizza: {number: "3" size: "large"}}".

execute

To execute executable content – either a block, a filled action, or a set of filled actions. If an event is thrown during execution, the execution of the executable content is aborted. The appropriate event handler is then executed, and this may cause control to resume in a form item, in the next iteration of the form's main loop, or outside of the form. If a is executed, the transfer takes place immediately, and the remaining executable content is not executed.

Here is the conceptual form interpretation algorithm. The FIA can start with no initial utterance, or with an initial utterance passed in from another dialog:

// // Initialization Phase //

foreach ( ,