Voice Extensible Markup Language (VoiceXML) 3.0

In addition to the Resource Controllers associated with elements like <form>, there is a top-level controller associated with the <vxml> element that is responsible for starting processing and deciding which Resource Controller to execute next (i.e., for <form> or other interaction element ). The top-level controller also holds session level properties and is responsible for returning results to the Flow Level when script execution terminates.

VoiceXML 3.0 document initialization takes place over two phases: "DOM Processing" and "Preparation for Execution". Both of these phases assume the required resources have already been created. Any errors in the initialization of the document or the creation of these resources MUST be thrown in the calling context. If that context was a VoiceXML document, then this MUST be an error.badfetch.

Note that while these phases are ordered, and the steps within the phases ordered, this is only a logical ordering. Implementations are allowed to use a different ordering as long as behave as if they were following the specified ordering.

After initialization, the semantic control flow does a <goto> to the initial Resource Controller. Once a RC is running, it invokes Resources and other RCs by sending them events. The DOM is not involved in this process. At various points in the processing, however, an RC may decide to raise an author-visible event. It does this by creating an event targeted at a specific DOM node and sending it back to the DOM. When the DOM receives the event, it performs the standard bubble/capture cycle with the target specified in the event. In the course of the bubble/capture cycle, various event handlers may fire. Their execution is a semantic action and occurs back in the semantic 'side' of the environment. The DOM sends messages back to the appropriate semantic objects to cause this to happen. Note that this means that the DOM must store some sort of link to the appropriate RCs. The event handlers may update the data model, execute script, or raise other DOM events. When the handler finishes processing on the semantic side, it sends a notification back to the DOM so that it can resume the bubble/capture phase. (N.B. This notification is NOT a DOM event.) When the DOM finishes the bubble/capture processing of the event, it sends a notification back to the RC that raised the event so that it can continue processing.

Transition controllers provide the basis for managing flow in VoiceXML applications. Resource controllers for some elements like <form> have associated transition controllers which influence how form items get selected and executed. In addition to form, there is a transition controller for each of the following higher VoiceXML scopes:

• A document-level transition controller associated with the <vxml> element's resource controller that is responsible for starting document processing and deciding which resource controller to execute next, i.e., for a <form> or other interaction element in the document.
• An application-level transition controller that is responsible for starting application processing and deciding which document-level resource controller to execute next.
• A top-level or session transition controller that manages the flow for a VoiceXML session. This top-level transition controller is responsible for starting session processing and also holds session level properties.
• The above transition controllers influence the selection of the first form item resource controller to execute, and subsequent ones through the session.

Whenever a form item or form or document finishes execution, the relevant transition controller is consulted for selecting the subsequent one for execution. To find the relevant transition controller, begin at the current resource controller and navigate along the associated VoiceXML element's parent axis until you reach a resource controller with an associated transition controller. For example, for a form item, the parent form's resource controller has the relevant transition controller.

When a transition controller runs to completion, control is returned to the next higher transition controller along with any results that need to be passed up. For example, when the last form item in a form is filled, the transition controller associated with the form returns control to the document level transition controller along with the results for the filled form. Control may be returned to the parent transition controller in case of such run to completion semantics as well as error semantics.

Here is a UML representation of the prompt queue. This state machine assumes that "queue" and "play" are separate commands and that a separate "play" will always be issued to trigger the play. When the "play" is issued, the systems plays any queued prompts, up to and including the first fetch audio in the queue. Then it halts, even if there are additional prompts or fetch audio in the queue and waits for another "play" command.

The prompt structure assumed here is fairly abstract. It consists of a specification of the audio along with optional parameters controlling playback (for example, speed or volume.) The audio may be presented in-line, as SSML or some other markup language, or as a pointer to a file or streaming audio source. Logically, URLs are dereferenced at the time the prompt is queued, but implementations are not required to fetch the actual media until the prompt in question is sent to the player device. Note that the player device is assumed to be able to handle both recorded prompts and TTS, and to be able to interpret SSML. Platforms are free to optimize their implementations as long as they conform to the state machine specified here. In particular, platforms may prefetch audio or begin TTS processing in the background before the prompt is sent to the player device. For applications that make use of VCR controls (speed up, skip forward, etc.), actual performance may depend on whether the platform has implemented such optimizations. For example, a request to skip forward on a platform that does not prefetch prompts may result in a long delay. Such performance issues are outside the scope of this specification.

This diagram assumes that SSML mark information is delivered in the Player.Done event, and that the player returns a Player.Done event when it is sent a 'halt' event (otherwise mark information would get lost on barge-in and hangup, etc).

Note that the "FetchAudio" state is shown stubbed out for reasons of space, and is expanded in a separate diagram below the main one.

Figure X: Prompt Queue Model

Figure Y: Fetch audio Model

The prompt queue resource can be controlled by means of the following events:

The prompt queue resource returns the following events to its invoker:

The prompt queue receives the following events from the underlying player:

and sends the following events to the underlying device:

The recognition resource works as follows: in its created state, grammars (or a voice model) are added to the resource and subsequently prepared on the device. Recognition with these grammars (or voice model) can be activated and suspended, and recognition results are returned.

When the recognition resource is ready to recognize (at least one active grammar and/or voice model), one or more recognition cycles may occur in sequence.

• A recognition cycle is initiated when the resource sends the device an event instructing it to listen to the input stream.
• A recognition cycle is terminated if the device sends the resource an error event, or the device is instructed to stop recognition by the resource. When terminated, the device removes partially or wholly processed input from its buffer, and resource awaits grammars (and/or voice model) to prepare.
• During the recognition cycle, the device may send events to the resource indicating ongoing recognition status, and recognition results describing one or more input sequences which match active grammars (and/or the voice model).
• During the recognition cycle, the device may receive instructions to suspend recognition. When the device is suspended, input is not buffered and the device must not send any events until it receives instructions to re-start or terminate recognition.
• When the resource receives recognition results from the device during the recognition cycle, it passes them to its controller. A recognition cycle is now complete and the resource awaits instructions either to start another recognition cycle or to terminate recognition.

Thus a recognition resource may enter multiple recognition cycles (as required for 'hotword' recognition), while requiring that a device, even if it has multiple instantiations, only produces one set of recognition results per recognition cycle.

The recognition resource is defined in terms of a data model and state model.

The data model is composed of the following elements:

• activeGrammars: an ordered list of grammars with which to recognize. Each item in the list contains the following information:
  • content: a URI or inline content to the grammar itself
  • properties: grammar-specific properties (vxml20: weight, mode, type, maxage, maxstale, etc)
  • listener: a resource controller associated with this grammar
• or activeVoiceModel: a voice model with which to perform verification or identification. It contains the following information:
  • content: a URI to the voice model
  • properties: model-specific properties
  • listener: a resource controller associated with this voice model
• properties: properties pertaining to the recognition process. These properties differ depending on the type of the recognition resource: for a DTMF recognition resource, the properties include DTMF properties; for ASR recognition resource, speech recognition properties; for SIV resource, SIV properties. The properties may also include platform-specific properties.
• controller: the resource controller to which recognition status, results and error events are sent.
• mode: the recognition resource's inputmode: 'voice' for an ASR recognition resource, 'dtmf' for a DTMF recognition resource, and 'siv' for an SIV resource.

The state model is composed of states corresponding to functional state: idle , preparing grammars / preparing voice model , ready to recognize , recognizing , suspended recognition and waiting for results .

In the idle state, the resource awaits events from resource controllers to activate grammars or a voice model for recognition on the device. The data model - activeGrammars or activeVoiceModel, properties, controller and mode - is (re-)initialized upon entry to this state: activeGrammars and activeVoiceModel are cleared, properties and controllers are set to null. If the resource receives an 'addGrammar' event, a new item is added to activeGrammars using grammar, properties and listener data in the event payload. If the resource receives a 'prepare' event, it updates its data model with event data: 'properties' with the properties event data and 'controller' is updated with the controller event data. Subsequent event notifications and responses are sent to the resource controller identified as the 'controller'. The recognition resource then moves into the preparing grammars (or preparing voice model ) state.

In the preparing grammars state, the resource behavior depends on whether activeGrammars is empty or not. If activeGrammars is empty (i.e. no active grammars are defined for this recognition resource), the resource sends the controller a 'notPrepared' event and returns to the idle state. If activeGrammar is non-empty, the resource sends a 'prepare' event to the device. The event payload includes 'grammars' and 'properties' parameters. The 'grammars' value is an ordered list where each list item is a grammar's content and its properties extracted from activeGrammars. The order of grammars in the 'grammars' parameter must follow the order in the activeGrammar data model. If the device sends a 'prepared' event, the resource sends a 'prepared' event to the controller and transitions into the ready to recognize state.

In the preparing voice models state, the resource behavior depends on whether activeVoiceModel is empty or not. If activeVoiceModel is empty (i.e. voice model is not defined for this resource), the resource sends the controller a 'notPrepared' event and returns to the idle state. If activeVoiceModel is non-empty, the resource sends a 'prepare' event to the device. The event payload includes 'voicemodel' and 'properties' parameters. The 'voicemodel' value is a URI to the voicemodel, and its properties are extracted from activeVoiceModel. If the device sends a 'prepared' event, the resource sends a 'prepared' event to the controller and transitions into the ready to recognize state.

When the recognition resource is in a ready to recognize state, it may receive a 'stop' event. In this case, the resource sends a 'stop' event to the device, and returns to the idle state. If the resource receives a 'listen' event, it sends a 'listen' event to the device and moves into the recognizing state .

When the resource is in a recognizing state , it can toggle between this state and a suspended recognizing state. If the resource receives a 'suspend' event, then it moves into the suspended recognizing state and sends the device a 'suspend' event which causes the device to suspend recognition and delete any buffered input. No input is buffered while the device is in a suspended state. If the resource then receives a 'listen' event, it moves back into the recognizing state .

When in the recognizing state , the resource may receive an 'inputStarted' event from the device, indicating that user input has been detected. The resource then moves into a waiting for results state. The device may send an 'error' event (for example, if maximum time has been exceeded) causing it to return to the idle state and send the controller an 'error' event. Alternatively, the device may send a 'recoResults' event, which contains a results parameter, a data structure representing recognition results. In the case of DTMF or ASR, the results can be in VoiceXML 2.0 or EMMA format. For SIV, the results must be in EMMA format. The structure may contain zero or more recognition results. Each result must specify the grammar (or voicemodel) associated with the recognition (using the same grammar/voicemodel name as used in the payload of the 'prepare' event), its recognition confidence and its input mode. The resource sends its controller a 'recoResults' event with event data containing the device's results parameter together with a listener parameter whose value is the listener associated with the grammar of the first result with the highest confidence (if there are no results, then the listener parameter is not defined). The resource then returns to the ready to recognize state , awaiting either a 'stop' event to terminate recognition or a 'listen' event to start another recognition cycle using the same active grammars and recognition properties.

A recognition resource is defined by the events it receives:

and the events it sends:

The resource receives from the recognition device the following events:

and sends to the recognition device the following events:

The state model for an ASR recognition resource are shown in Figure 9. The DTMF resource model only differs in that the value for the mode data is 'dtmf' instead of 'voice'.

[generalize stop event returning resource to idle state ...]

Figure 9: Recognition Resource States

A connection resource is an entity that establishes/relinquishes a connection between the VoiceXML interpreter context and the user. It can be used by the interpreter context to establish a connection with the user at the start of the dialog or to disconnect an existing connection either implicitly (when there are no more elements to execute in the VoiceXML application) or explicitly (when the interpreter context encounters a <disconnect> element or the user chooses to terminate the call).

Whenever an interpreter context disconnects from the user, the interpreter context may enter into the final processing state as is the case while executing a <disconnect> element or when the user actively disconnects. The purpose of this state is to allow the VoiceXML application to perform any necessary final cleanup, such as submitting information to the application server. In this state, entering into the wait state is not allowed. However, the application can navigate from one page to another without trying to interact with the user. Therefore, the application should not enter <field>, <record> or <transfer> during the final processing state. The VoiceXML interpreter must exit if the VoiceXML application attempts to enter the waiting state while in the final processing state.

Aside from this restriction, execution of the VoiceXML application continues normally while in the final processing state. Thus for example the application may transition between documents while in the final processing state, and the interpreter must exit if no form item is eligible to be selected.

[TBD]

[TBD]

The timer resource is a resource that tracks timers for various resource controllers. A timer can be set to send a timeout event at some future time. Timers which have been set may also be canceled.

A timer resource is defined by the events it receives:

and the events it sends:

t is possible to receive both a timerExpired event and then a cancelSuccess event as the events may have crossed paths.

The resource receives from the timer device the following events:

and sends to the timer device the following events:

TBD

The grammar RC is the primary RC for the <grammar> element.

The events in this table may be raised during initialization and execution of the <grammar> element.

Note that additional errors may occur when the grammar is fetched or added by the ASR or DTMF resource. Please check there for details.

[TBD: put all examples here.]

[See XXX for schema definitions].

No module-specific events are raised during initialization of an Inline SRGS Grammar. Note that validity failure of the inline SRGS content would be detected at document parse time.

[TBD: put all examples here.]

The <externalgrammar> element has the following co-occurrence constraints:

• Exactly one of the "src" or "srcexpr" attributes must be specified; otherwise, an error.badfetch event is thrown.

The events that may be raised during initialization and execution of the <externalgrammar> element are those defined in Table 27 below.

[TBD: put all examples here.]

The prompt RC is the primary RC for the <prompt> element.

The events in Table 32 may be raised during initialization and execution of the <prompt> element.

[TBD: put all examples here.]

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

In this example

<prompt>
 <foreach item="item" array="array">
    <audio expr="item.audio"><value expr="item.tts"/></audio>
    <break time="300ms"/>
 </foreach>
</prompt>

evaluation returns a sequence of content for each item in <foreach> with <audio> and <value> elements.

Assume that the array consists of 2 items where each item.audio evaluates to 'one.wav' and 'two.wav' respectively, and each item.tts evaluates to 'one' and 'two' respectively. Evaluation of <foreach> is equivalent to the following

<prompt>
    <audio expr="'one.wav'"><value expr="'one'"/></audio>
    <break time="300ms"/>
    <audio expr="'two.wav'"><value expr="'two'"/></audio>
    <break time="300ms"/>
</prompt>

further evaluation of the <audio> and <value> elements result in

<prompt>
    <audio src="one.wav">one</audio>
    <break time="300ms"/>
    <audio src="two.wav">two</audio>
    <break time="300ms"/>
</prompt>

and finally the prompt content is converted into a stand-alone SSML document (assuming the <prompt>'s xml:lang attribute evaluates to 'en'):

<speak version="1.0" xml:lang="en" 
 xmlns="http://www.w3.org/2001/10/synthesis">
    <audio src="one.wav">one</audio>
    <break time="300ms"/>
    <audio src="two.wav">two</audio>
    <break time="300ms"/>
</speak>

This content is queued and played using the PromptQueue: each audio URI, or fallback content, is played, followed by a 300 millisecond break.

When an media RC receives an evaluate event, the following operations are performed:

• attributes with data model expressions are evaluated against the data model
• if inline SSML content is specified (i.e. <speak> root), then its RC is sent an evaluate event (where any <foreach> and <value> elements are evaluated).
• if inline CDATA content (i.e. CDATA root), or <foreach> and <value> root elements which evaluate to CDATA content, then it is treated as SSML <speak> content.
• if the media resource has not yet been fetched, the resource is fetched. If SSML content is specified, then the evaluated content is processed by the SSML processor and a media resource returned.

The resulting media resource is returned together with resolved media operation properties (clipBegin, clipEnd, soundLevel, speed, outputmodes).

Playback of external audio media resource.

<media type="audio/x-wav" src="http://www.example.com/resource.wav"/>

Application of media operations to audio resource. The soundLevel increases the volume by approximately 50% and the speed is reduced to 50%.

<media type="audio/x-wav" soundLevel="+6.0dB" speed="50%" 
       src="http://www.example.com/resource.wav"/>

Playback of 3GPP media resource.

<media type="video/3gpp" src="http://www.example.com/resource.3gp"/>

Playback of 3GPP media resource with the speed doubled and playback ending after 5 seconds.

<media type="video/3gpp" clipEnd="5s" speed="200%" 
       src="http://www.example.com/resource.3gp"/>

Playback of external SSML document.

<media type="application/ssml+xml" 
       src="http://www.example.com/resource.ssml"/>

Inline CDATA content with a <value> element

<media>
    Ich bin ein Berliner, said <value expr="speaker"/>
</media>

which is syntactically equivalent to

<media>
   <speak version="1.0" xmlns="http://www.w3.org/2001/10/synthesis">
    Ich bin ein Berliner, said <value expr="speaker"/>
    </speak>
</media>

Inline SSML content to which gain and clipping operations are applied.

<media soundLevel="+4.0dB" clipBegin="4s">
   <speak version="1.0" xmlns="http://www.w3.org/2001/10/synthesis">
    Ich bin ein Berliner.
    </speak>
</media>

Inline SSML with audio media fallback.

<media volume="+4.0dB" clipBegin="4s">
   <speak version="1.0" xmlns="http://www.w3.org/2001/10/synthesis">
    Ich bin ein Berliner.
    </speak>
    <media type="audio/x-wav" src="ichbineinberliner.wav">
</media>

The <par> element is derived from SMIL <par> element, a time container for parallel output of media resources. Media elements (or containers) within a <par> element are played back in parallel.

The <par> element has the attributes specified in Table 35.

The content model of <par> consists of:

• <media> elements (0 or more)
• <seq> elements (0 or more)

The <par> element is derived from SMIL <seq> element, a time container for sequential output of media resources. Media elements within a <seq> element are played back in parallel.

No attributes are defined for <seq>.

The content model of <seq> consists of:

• <media> elements (0 or more)

This module requires a PromptQueue resource which support playback of parallel and sequential media. The following defines its playback completion, termination and error handling.

Completion of playback of the <par> element is determined according to the value of its endsync attribute. For instance, assume a <par> element containing <media> (or <seq>) elements A and B, and that B finishes before A. If endsync has the value first, then completion is reported upon B's completion. If endsync has the value last, then completion is reported upon A's completion.

Completion of playback of the <seq> element occurs when the last <media> is complete.

If the <par> element playback is terminated, then playback of its <media> and <seq> children is terminated. Likewise, if the <seq> element playback is terminated, then playback of its (active) <media> elements is terminated.

If mark information is provided by <media> elements (for example with SSML), then, the mark information associated with last element played in sequence or parallel is exposed as described in XXX.

Error handling policy is inherited from the element in which <par> and <seq> element are children.

For instance if the policy is to ignore errors, then the following applies:

• If an error occurs when playing a <media> element in <par>, then the error is ignored.
• Likewise, if there is an error playing back a <media> element in <seq>, the error is ignored and the next <media> element in the sequence, if there is one, is played.
• If the <media> element in which the error occurs is the final one in the <par> element, then completion of <par> playback is signaled when the error is detected.

If the policy is to terminate playback and report the error, then the any error causes immediate termination of any playback and the error is reported.

If execution of the <par> and <seq> elements requires media capabilities which are not supported by the platform or the connection, or there is an error fetching or playing any <media> element within <par> or <seq>, then error handling follows the defined policy.

video avatar with audio commentary. Note the use of the outputmodes attributes of <media> to ensure that only video is played.

 <par>
   <media type="audio/x-wav" src="commentary.wav"/>
   <media type="video/3gpp" src="avatar.3gp" outputmodes="video"/>
 </par>

video avatar with a sequence of audio and TTS commentary.

 <par>
   <seq>
     <media type="audio/x-wav" src="intro.wav"/>
     <media type="application/ssml+xml" src="commentary.ssml"/>
   </seq>
   <media type="video/3gpp" src="avatar.3gp" outputmodes="video"/>
 </par>

When the RC receives an evaluate event, the RC loops through the array to produce an evaluated content for each item in the array.

The vxml21 profile defines the content model for the <foreach> element so that it may appear in executable content and within <prompt> elements.

Within executable content, except within a <prompt>, the <foreach> element may contain any elements of executable content; this introduces basic looping functionality by which executable content may be repeated for each element of an array.

When <foreach> appears within a <prompt> element as part Builtin SSML content, it may contain only those elements valid within <enumerate> (i.e. the same elements allowed within <prompt> less <meta>, <metadata>, and <lexicon>); this allows for sophisticated concatenation of prompts.

In this example using Builtin SSML, each item in the array has an audio property with a URI value, and a tts property with SSML content. The element loops through the array, playing the audio URI or the SSML content as fallback, with a 300 millisecond break between each iteration.

<prompt>
 <foreach item="item" array="array">
    <audio expr="item.audio"><value expr="item.tts"/></audio>
    <break time="300ms"/>
 </foreach>
</prompt>

In the mediaserver profile, <foreach> may occurs within <prompt> elements and has the content model of 0 or more <media> elements.

Play each media resource in the array.

  <foreach item="item" array="array">
   <media type="audio/x-wav" src="item.audio"/>
  </foreach>

Play each media resource in the array.

<foreach item="item" array="array">
   <media type="audio/x-wav" src="item.wav">
   <media type="application/ssml+xml">
    <speak version="1.0" xmlns="http://www.w3.org/2001/10/synthesis">     
     <value expr="item.tts"/>
     <break time=300ms"/>
     </speak>
   </media>
 </media> 
</foreach>

Forms are the key component of VoiceXML documents. A form contains:

• A set of form items, elements that are visited in the main loop of the form interpretation algorithm. Form items are subdivided into input items that can be 'filled' by user input and control items that cannot.
• Declarations of non-form item variables.
• Event handlers.
• "Filled" actions, blocks of procedural logic that execute when certain combinations of input item variables are assigned.

VoiceXML developers are commonly required to sketch out an application for the purpose of a demo or other proof of concept. In such cases, it is convenient to use placeholder grammars for frequent dialogs like collecting a date, asking a yes/no question, etc. Builtin grammars (provided by the platform) are designed to serve this purpose.

Once the prototyping phase is complete, however, it is good practice to replace the builtin grammar references with developer written grammars. There are several reasons behind this suggestion:

• There is little consistency of the builtin implementations across platforms. Relying on builtins complicates portability.
• Application developers typically have no control over the coverage in the builtin grammar. This means that any modification to the accepted phrase(s) would require a completely new grammar. Discovering a limitation like this post-deployment could be disruptive.
• Similar to the above, builtins are limited in their ability to handle underspecified spoken input. For instance, "20 peso" cannot be resolved to a specific [ISO4217] currency code because the "peso" is the name of the currency of numerous nations. In such cases the platform may return a specific currency code according to the language or may omit the currency code. Edge cases like this are not likely to be handled by platform builtins.

• Supporting all builtin types for a given language. In other words, if a platform supports one builtin in a language, then it ought to support the others as well.
• Following the type descriptions listed in the "Syntax and Semantics" section below. This requirement is primarily designed to ensure at least some amount of consistency on how the NL from the grammar is accessed.
• Supporting both voice and DTMF modes for each type.
• Supporting the corresponding <say-as> class for the grammar type.

Builtin grammars may be specified in one of two ways:

• Through the "type" attribute on the <field> tag (see Table 41). For example <field type="boolean">. Note that when a builtin is specified in this way, it is in addition to any <grammar> under the <field>
• Using the "builtin" protocol for the grammar URI. For example: <grammar src="builtin:boolean"/>

Each builtin type has a convention for the format of the value returned. These are independent of language and of the implementation. The return type for builtin fields is a string except for the boolean field type. To access the actual recognition result, the author can reference the <field> shadow variable "name$.utterance". Alternatively, the developer can access application.lastresult$, where application.lastresult$.interpretation has the same string value as application.lastresult$.utterance.

Both the "boolean" and "digits" types can be parameterized as follows:

Note that more than one parameter may be specified separated by the ";" character. This is illustrated in the last example below.

A <field> element with a builtin grammar type. In this example, the boolean type indicates that inputs are various forms of true and false. The value actually put into the field is either true or false. The field would be read out using the appropriate affirmative or negative response in prompts.

            <field name="lo_fat_meal" type="boolean">
                
                <prompt>
                    Do you want a low fat meal on this flight?
                </prompt>
                <help>
                    Low fat means less than 10 grams of fat, and under
                    250 calories.
                </help>
                <filled>
                    <prompt>
                        I heard <emphasis><say-as interpret-as="vxml:boolean">
                            <value expr="lo_fat_meal"/></say-as></emphasis>.
                    </prompt>
                </filled>
            </field>            
           

In the next example, digits indicates that input will be spoken or keyed digits. The result is stored as a string, and rendered as digits using the <say-as> with "vxml:digits" as the value for the interpret-as attribute, i.e., "one-two-three", not "one hundred twenty-three". The <filled> action tests the field to see if it has 12 digits. If not, the user hears the error message.

                <field name="ticket_num" type="digits">
                    <prompt>
                        Read the 12 digit number from your ticket.
                    </prompt>
                    <help>The 12 digit number is to the lower left.</help>
                    <filled>
                        <if cond="ticket_num.length != 12">
                            <prompt>
                                Sorry, I didn't hear exactly 12 digits.
                            </prompt>
                            <assign name="ticket_num" expr="undefined"/>
                            <else/>
                            <prompt>I heard <say-as interpret-as="vxml:digits"> 
                                <value expr="ticket_num"/></say-as>
                            </prompt>
                        </if>
                    </filled>
                </field>            
           

The builtin boolean grammar and builtin digits grammar can be parameterized. This is done by explicitly referring to builtin grammars using a platform-specific builtin URI scheme and using a URI-style query syntax of the form type?param=value in the src attribute of a <grammar> element, or in the type attribute of a <field>. In this example, the <grammar> parameterizes the builtin DTMF grammar, the first <field> parameterizes the builtin DTMF grammar (the speech grammar will be activated as normal) and the second <field> parameterizes both builtin DTMF and speech grammars. Parameters which are undefined for a given grammar type will be ignored; for example, "builtin:grammar/boolean?y=7".

            <grammar src="builtin:dtmf/boolean?y=7;n=9"/>
            
            <field type="boolean?y=7;n=9">
                <prompt>
                    If this is correct say yes or press seven, if not, say no or press nine.
                </prompt>
            </field>
            
            <field type="digits?minlength=3;maxlength=5">
                <prompt>Please enter your passcode</prompt>
            </field>            
       

Information in the Data layer must be easily accessible and easily editable throughout the VoiceXML 3.0 document. The Data Access and Manipulation Module describes the necessary mechanics by which application developers can express such interactions with the Data layer. Implementers must augment the data access and manipulation languages supported to provide the capabilities described in this section.

The remainder of this Section covers the semantics of the Data Access and Manipulation Module in Section 2.2 and the corresponding syntax in Section 2.3. Backward compatibility with VoiceXML 2.1 is discussed in Section 2.4.

The semantics of Data Access and Manipulation can be described in terms of the various scopes in VoiceXML 3.0, the relevance to platform properties, the corresponding implicit variables that platforms must support, the variable resolution mechanism, standard session and application variables and the set of legal data values and expressions.

The syntax of the Data Access and Manipulation Module is described in terms of full support for CRUD operations (Create, Read, Update, Delete) on the Data layer in sections 2.3.1 through 2.3.4. The relevance of this syntax for properties is described in section 2.3.5.

VoiceXML 3.0 adds some new features to data access and manipulation but does not change any existing behavior. Thus, this module is backwards compatible with Voice XML 2.1.

Likewise, the VoiceXML 2.1 profile in VoiceXML 3.0 is not required to support any of the new features added in this module. In particular, the following features may be excluded by implementors supporting the VoiceXML 2.1 profile.

Implicit variables described in section 2.2.3 to qualify scope are amenable to certain data access and manipulation languages (such as ECMAScript) but are not as elegant while incorporating in the syntax of others, such as XPath. VoiceXML 3.0 permits the use of functions rather than variables to address this. The following table illustrates how scope qualifiers are exposed as XPath functions.

The following table shows how these qualifier functions are used, and the examples are XPath variants of the examples illustrated in Table 53.

Because external messages can arrive at any time, they can be disruptive to a voice application. A voice application developer decides whether these messages are delivered to the application synchronously or asynchronously using the "externalevents.enable" property. The property can be set to one of the following values:

When external messages are delivered synchronously, an application developer decides whether these messages are preserved or discarded by setting the "externalevents.queue" property. The property can be set to one of the following values:

To send a message from a VoiceXML application to a remote endpoint, use the <send> element. <send> is allowed within executable content . Implementations must support the following attributes:

Only one of async and asyncexpr can be specified or "error.badfetch" is thrown.

Only one of event or eventexpr can be specified or "error.badfetch" is thrown.

Only one of body, bodyexpr, namelist, event, or eventexpr must be specified or "error.badfetch" is thrown.

Only one of contenttype and contenttypeexpr can be specified or "error.badfetch" is thrown.

Only one of fetchaudio and fetchaudioexpr can be specified or "error.badfetch" is thrown.

Only one of target and targetexpr can be specified or "error.badfetch" is thrown.

Only one of timeout and timeoutexpr can be specified or "error.badfetch" is thrown.

When present, the attributes asyncexpr, bodyexpr, contenttypeexpr, eventexpr, fetchaudioexpr, targetexpr, and timeoutexpr are evaluated when the <send> is executed.

If a synchronous <send> succeeds, execution proceeds according to the Form Interpretation Algorithm. If the <send> times out, the interpreter throws "error.badfetch" to the application. If the interpreter encounters an error upon sending the external message, the interpreter throws "error.badfetch.<protocol>.<status_code>" to the application. If no status code is available, the interpreter throws "error.badfetch.<protocol>".

The following example demonstrates the use of <send> synchronously:

<vxml version="2.1"
  xmlns="http://www.w3.org/2001/vxml">
  <form>
  <field name="user_id" type="digits">
    <prompt>please type your five digit i d</prompt>
    <filled>
      <send async="false" 
            bodyexpr="'&lt;userinfo&gt;&lt;id&gt;' + user_id + '&lt;/id&gt;&lt;/userinfo&gt;'" 
            contenttype="text/xml"/>
      <goto next="mainmenu.vxml"/>
    </filled>
  </field>
  </form>
</vxml>

Upon executing an asynchronous <send>, the interpreter continues execution of the voice application immediately and disregards the disposition of the message that was sent.

The following example demonstrates the use of <send> asynchronously:

<vxml version="2.1"
  xmlns="http://www.w3.org/2001/vxml">
  <form>
    <var name="tasktarget" expr="'http://www.example.com/taskman.pl'"/>
    <var name="taskname" expr="'cc'"/>
    <var name="taskstate"/>
    <block>
      <assign name="taskstate" expr="'start'"/>     
      <send async="true" 
            targetexpr="tasktarget" 
            namelist="taskname taskstate"/>
    </block>
    <field name="ccnum"/>
    <field name="expdate"/>
    <block>
      <assign name="taskstate" expr="'end'"/>     
      <send async="true" 
            targetexpr="tasktarget" 
            namelist="taskname taskstate"/>
    </block>
  </form>
</vxml>

The syntax of the session root module defines the addition of two attributes on the root <vxml> element. These two new attributes are summarized below.

For the sake of compactness assume throughout this example that the single letters used are actually fully qualified URIs. A VXML document "A" transitions to VXML document "B" which is partially represented below:

<vxml session="C" application="D" … >

Before "B" can finish initialization of "B" it loads, parses, and initializes the VXML documents at both "C" and "D". While executing in "B" any grammars, properties, links, and variables included from either "C" or "D" influence execution. Document "B" then transitions to document "E", with no session attribute, partially represented below:

<vxml application="D" … >

While executing in "E" having come from "B", everything from both "C" and "D" are still active. "D" is still active as we haven't left the application yet. "C" is still active as we are part of the same session. Document "E" now transitions to document "F" partially represented below:

<vxml application="G" … >

Now, since we have changed applications, the application root document form "D" is unloaded and grammars, variables, properties, etc. from "D" are no longer influencing our execution. Document "G" defines our application root and it, along with "C" which is still active since we are in the same session, now influence our execution. Document "F" now transitions to "H" partially represented below:

<vxml session="I" … >

Now, since there is already "C" as our session root document defined we cannot load document "I" and treat this as our session root. In the absence of requiresession "I" is ignored and "H" is executed using "C" as our session document. If instead "H" looked as below:

<vxml session="I" requiresession="true" … >

Now "H" would fail to load and execution would revert to document "F" where the appropriate error.badfetch for "H" would be thrown.

<cancelrtc> can be used to cancel an rtc defined by the <rtc> element. Note that rtcs are identified by their grammars.

Logically rtc grammars behave as a prefilter on the speech stream, replacing any input they match with silence. Since rtc grammars operate upstream of normal recognition grammars, the recognition grammars never see input that matched an rtc grammar. Thus input that matches an rtc grammar will not trigger barge in, since barge-in is triggered only by input matching a normal recognition grammar. Since rtc grammars apply upstream of recognition grammars, all rtc grammars have, in effect, a higher priority than any recognition grammar. Thus the priority attribute on an rtc grammar affects its priority only relative to other rtc grammars.

When processing speech or type-ahead input, rtcs again apply upstream of normal speech grammars. Remember also that rtcs may be active even when the system is not in the wait state, so they may match the input while it is being entered and other grammars are not active.

The platform executes the 'volume', 'speed' and 'skip' actions immediately, as soon as the rtc grammar matches. The platform also executes the 'cancel' and 'goto' actions automatically, but only once the interpreter is in an event-processing state. Thus the platform may complete the processing of non-interruptable tasks before it processes the 'cancel' or 'goto' actions.

T.B.D.

The core functions of SIV processing are divided into creating a voice model and enrolling a user in the system (Enrollment) and using a pre-existing voice model (either Verification or Identification). Additionally, some engines support adaptation of an existing voice model based on new user utterances. An SIV dialog may consist of a sequence of one or more SIV dialog turns.

The SIV resource is defined in terms of a data model and state model. The data model is composed of the following elements:

• activeVoiceModel:
  • content: a URI reference to the voice model (or the voice model itself) with which to perform verification or identification.
  • properties: type, vendor, etc.
  • listener: a resource controller associated with this SIV resource
• properties: properties pertaining to the SIV process. These properties differ depending on the type of the SIV resource type and function
  • Resource type
    • text-dependent
    • text-independent
    • other types
  • Function
    • Enrollment
    • Verification
    • Identification
  • Platform-specific
• controller: the resource controller to which status, results and error events are sent.

An SIV Resource manages SIV devices during a processing cycle:

• An SIV cycle is initiated when the resource sends the device an event instructing it to listen to the input stream.
• An SIV cycle is terminated if the device is instructed to stop by the resource, if the device sends the resource an error event, or the device ends processing early. When terminated, the device removes partially or wholly processed input from its buffer and discards the voicemodel.
• During an SIV cycle, the device may send events to the resource indicating ongoing status.
• When the resource receives results from the device during the SIV cycle, it passes them to its controller. At this point the SIV cycle is complete and the resource awaits instructions either to start another SIV cycle or to terminate.

The voicemodel RC is the primary RC for the <voicemodel> element.

The events in this table may be raised during initialization and execution of the <voicemodel> element.

[Examples TBD]

TBD.

TBD

TBD

The disconnect RC is the primary RC for the <disconnect> element.

Whenever a particular property needs to be used, its value must be looked up. The mechanism to lookup the value of a property is dependent on both the syntactic structure of the authored document and the current location in execution. The timing of whenever a property needs to be used is dependent on the property in question. For instance, the speedvsaccuracy recognizer property needs to have its value be looked up whenever a recognition is to take place (like in a <field> tag) but it doesn't need to be looked up at other times like when a generic prompt is queued in a block or when a script file is fetched. In contrast, a property like bargein needs to be looked up whenever a prompt is queued in a block and the scripttimeout property needs to be looked up whenever a script file is loaded. For a more complete list of individual properties and when they are evaluated see section 8 on environment that lists the various properties and details about them.

When a property is looked up first it must be determined if this property is defined at the current execution level. If it is then the last instance of the property element is the one that is evaluated and used. If no property elements for this property exist at the current document level then the next higher level XML container is checked, including going to application root documents and session root documents. This parent chain is halted whenever the property is found. The chain of parents to follow for a look up can span a number of different document elements. For instance it may have had to be looked up at the current level (I.e., is there a property defined in the field), the dialog level (I.e., what about in the form), the document level (I.e., what about in the vxml element), the application level (I.e., what about the application root), the session level (I.e., what about the session root). If the property isn't found at any of these levels then either a specification specified default or a platform default may need to be used (see the platform root). For instance the speedvsaccuracy default value is defined to be 0.5 by the VXML specification. The completetimeout property however has no specification default and instead must use a platform default if it is not present.

If the platform has trouble evaluating the value of a property (I.e., an expr failure) or the value of a property is invalid (I.e., a completetimeout of "orange") then the platform should throw error.semantic.

[Events raised during initialization and execution TBD.]

[TBD: put all examples here.]

Transition controllers serve as dialog managers for VoiceXML forms and documents and are described syntactically using the <controller> element. A VoiceXML 3.0 <form> element or <vxml> element may have at most one <controller> child, which allows mixed content.

The controller RC is the primary RC for the <controller> element.

Whenever a form item or form or document finishes execution, the relevant transition controller is consulted for selecting the subsequent one for execution. To find the relevant transition controller, begin at the current resource controller and navigate along the associated VoiceXML element's parent axis until you reach a resource controller with an associated transition controller. For example, for a form item, the parent form's resource controller has the relevant transition controller.

When a transition controller runs to completion, control is returned to the next higher transition controller along with any results that need to be passed up. For example, when the last form item in a form is filled, the transition controller associated with the form returns control to the document level transition controller along with the results for the filled form. Control may be returned to the parent transition controller in case of such run to completion semantics as well as error semantics.

EXAMPLE 1: If the transition controller is described using an XML type or vocabulary, the description is a direct child of the <controller> element.

<v3:vxml version="3.0" ...>
  <!-- document level transition controller, type defaults to SCXML -->
  <v3:controller id="controller" type="application/xml+scxml">
    <scxml:scxml version="1.0" ...>
      <!-- Transition controller as a state chart -->
    </scxml:scxml>
  </v3:controller>
  <!-- Remainder of VoiceXML 3.0 document -->
</v3:vxml>

EXAMPLE 2: If the transition controller is described using a non-XML type or vocabulary, the description is the text content of the <controller> element. A CDATA section may be used if needed.

<v3:vxml version="3.0" ...>
  <!-- document level transition controller -->
  <v3:controller id="controller" type="text/some-controller-notation">
    <![CDATA[
      // Some text-based transition controller description
    ]]>
  </v3:controller>
  <!-- Remainder of VoiceXML 3.0 document -->
</v3:vxml>

EXAMPLE 3: [Support for this convenience syntax not yet decided -- here's the tentative text: If the transition controller is described using SCXML, then a convenience syntax of placing the <scxml> root element as a direct child of the <vxml> or <form> element is supported without the need of a <controller> wrapper. Thereby, the following two variants are equivalent:]

<v3:vxml version="3.0" ...>
  <v3:controller>
    <scxml:scxml version="1.0" ...>
      <!-- Transition controller as a state chart -->
    </scxml:scxml>
  </v3:controller>
  <!-- Remainder of VoiceXML 3.0 document -->
</v3:vxml>
Variant 2:
<v3:vxml version="3.0" ...>
  <scxml:scxml version="1.0" ...>
    <!-- Transition controller as a state chart -->
  </scxml:scxml>
  <!-- Remainder of VoiceXML 3.0 document -->
</v3:vxml>

This section defines semantics of how different modules coexist with each other to simulate the behavior of VoiceXML 2.1. It outlines all the required modules and any additions/deletions from each of these modules to make it conform to this profile. It also talks about the interaction amongst various modules so that behavior similar to that in VoiceXML 2.1 is achieved.

To conform with this profile, processors must implement the following modules:

This section describes the convenience syntax that can be used to define some of the functionality of VoiceXML 2.1.

This section describes what we refer to as the Form Interpretation Algorithm (FIA) in VoiceXML 2.1 using Transition Controllers defined in VoiceXML 3.0.

The basic profile provides basic media capabilities including the capture and presentation of temporal media such as audio and video. The basic profile serves two different purposes:

• To provide core temporal media services in high-volume applications, particularly in telecom networks and NGN, IMS, etc.
• To support mobile devices with embedded temporal media capabilities, especially speech technology.

The basic profile is a "lean and mean" collection of media functions which the application can invoke, but does not duplicate functions from the scripting or programming languages.

The basic profile is intended for single-turn prompt and collect applications.

The following enumerates the modules included in the Basic Profile.

Results are returned using EMMA notation, which may include includes confidence scores and multiple results represented in a lattice.

The basic profile does NOT support the capture of key strokes, mouse movements, or joystick movements and does not present static information such as text and bit map graphics on a display. Other languages such as HTML, SVG, and XHTML can be used to perform these functions.

The basic profile does NOT support higher-level flow control constructs such as the VoiceXML 2.0 <form> element and the associated Form Interpretation Algorithm. The Basic Profile assumes that application developers specify flow control using a scripting or programming language, which controls all application-specific procedural flow and interaction with non-VoiceXML functions such as databases, application functions, and Web services.

The following VoiceXML 2.0/2.1 control elements are NOT included in the Basic Profile:

• <foreach>
• <form> and the associated Form Interpretation Algorithm (FIA)
• <goto>
• <submit>
• <exit>
• <return>
• <disconnect>
• <if>
• <else>
• <elseif>
• <reprompt>
• <log>
• <help>
• <link>
• <noinput>
• <nomatch>
• <object>
• <param>
• <subdialog>

Example of an application using SCXML and modules of the basic profile [tbd]

Example of a programming or scripting language and modules of the basic profile [tbd]

A VoiceXML interpreter context needs to fetch VoiceXML documents, and other resources, such as media files, grammars, scripts, and XML data. Each fetch of the content associated with a URI is governed by the following 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 <subdialog>, <goto>, <submit>, <link>, or <choice> 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, <submit> always results in a fetch, and if a fragment is accompanied by a namelist attribute there will also be a fetch.

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 <submit> 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.

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

The following generic speech recognition properties are defined.

The following generic DTMF recognition properties are defined.

The following properties are defined to apply to the fundamental platform prompt and collect cycle.

The following properties are defined to apply to output media.