Voice Extensible Markup Language (VoiceXML) 3.0

4.2.1 Top Level Controller

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.

4.4.1 Internal Events

The event model for VoiceXML 3.0 builds upon the DOM Level 3 Events [DOM3Events] specification. DOM Level 3 Events offer a robust set of interfaces for managing the listener registration, dispatching, propagation, and handling of events, as well as a description of how events flow through an XML tree.

The DOM 3.0 event model offers VoiceXML developers a rich set of interfaces that allow them to easily add behavior to their applications. In addition, conforming to the standard DOM event model enables authors to integrate their Voice applications in next generation multimodal or multi-namespaced frameworks such as MMI and CDF with minimal efforts.

Within the VoiceXML 3.0 semantic model, the DOM Level 3 Events APIs are available to all Resource Controllers that have markup elements associated with them. Indeed, this section covers the eventing APIs as available to VoiceXML 3.0 markup elements. The following section describes how the semantic model ties in with the DOM eventing model.

      
      {"http://www.example.org/2007/v3","connection"} 
      
   

      
      {"http://www.example.org/2007/v3","connection.disconnect"}
      {"http://www.example.org/2007/v3","connection.disconnect.hangup"}
      
   

4.4.2 External Events

VoiceXML 3.0 interpreters may receive events from external sources, for example SCXML engines. In particular, it may receive the life cycle events specified as part of the Multimodal Architecture and Interfaces specification [MMI]. These life cycle events allow the flow component of the DFP architecture to control the presentation layer by starting and stopping the processing of markup. By handling these events, the VoiceXML interpreter acts as a 'modality component' in the multimodal architecture, while the flow component acts as an 'interaction manager'. As a result, VoiceXML 3 applications can be easily extended into multimodal applications. However it is important to note that support for the life cycle events is required by the DFP framework in all applications, whether uni- or multimodal.

The interpreter must handle the following life cycle events automatically:

• PrepareRequest. This event instructs the interpreter to prepare to run a VoiceXML script. The event contains: a) either the URI of the markup to run or the actual markup itself, b) a context ID which will be used in subsequent messages referring to the same markup, and c) a specification of media channel to use. Note that the interpreter does not actually start running the markup in question when it receives this message. Once the interpreter has finished its preparation, it sends a PrepareResponse event in reply. The PrepareResponse event contains the context ID that was sent in the PrepareRequest plus a status field containing 'success' or 'failure'. This message with a status of 'success' thus indicates that the interpreter is now ready to run the specified markup.
• StartRequest. This event instructs the interpreter to run the specified script. It will contain the same context ID as the preceding PrepareRequest, and may optionally contain a new specification of the markup to run and the media channel to use, overriding those contained in the PrepareRequest. This event may also be sent without a preceding PrepareRequest. When the interpreter receives this event, it must start running the specified markup using the specified media channel. It will then send a StartResponse event in reply.
• CancelRequest with 'immediate' flag set to true. This event instructs the interpreter to disconnect from the media and to stop processing the markup. This event contains the context ID. The interpreter may continue processing clean-up handlers etc. after it receives this event, but it should not end any events back to the sender other than the CancelResponse, which acknowledges the receipt of this command. If the 'immediate' flag is set to false, the interpreter passes the event up to be handled by author code, as described below.
• ClearContextRequest???

All other life cycle events and all other external events are ignored unless the External Communications Module 6.13 External Communication Module is included in the profile. If the External Communications Module is present, all other external events are passed up to the application, placed in the application event queue and then handled as specified by the developer using the functionality defined in that module.

4.5.1 Initialization

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.

4.5.2 Execution

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.

4.5.3 Transition Controllers

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.

5.1.1 Data Model Resource API

5.2.1 State Chart Representation

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

5.2.2 SCXML Representation

<?xml version="1.0" encoding="UTF-8"?>

<scxml initialstate="Created">
  <datamodel>
    <data name="queue"/>
    <data name="markName"/>
    <data name="markTime"/>
    <data name="bargeInType"/>
  </datamodel>

   <state id="Created">
    <initial id="Idle"/>

    <transition event="QueuePrompt">
     <insert  pos="after" loc = "datamodel/data[@name='queue']/prompt" val="_eventData/prompt"/>
    </transition>

     <transition event="QueueFetchAudio">
       <foreach var="node" nodeset="datamodel/data[@name='queue']/prompt"> 
         <if cond="$node[@fetchAudio='true']">
          <delete loc="$node"/>
         <else>
          <assign loc="$node[@bargeInType]" val="unbargeable"/>
         </else>
         </if>
       </foreach>
    <insert pos="after" name="datamodel/data[@name='queue']/prompt" val="_eventData/audio"/>
    </transition>

    <transition event="setParameter">
     <send target="player" event="setParameter" namelist="_eventData.paramName, _eventData.newValue"/>
    </transition>

    <transition event="Cancel" target="Idle">
     <send target="player" event="halt"/>
     <send event="PlayDone" namelist="/datamodel/data[@name='markName'].text(), /datamodel/data[@name='markTime'].text()"/>
     <delete loc="datamodel/data[@name='queue']/prompt"/>
    </transition>

    <transition event="CancelFetchAudio">
       <foreach var="node" nodeset="datamodel/data[@name='queue']/prompt"> 
         <if cond="$node[@fetchAudio='true']">
          <delete loc="$node"/>
         </if>
       </foreach>
    </transition>

    <state id="Idle">
     <onentry>
      <assign loc="/datamodel/data[@name='markName']" val=""/>
      <assign loc="/datamodel/data[@name='markTime']" val="-1"/>
      <assign loc="/datamodel/data[@name='bargeInType']" val=""/>
     </onentry>

     <transition event="Play" cond="/datamodel/data[@name='queue']/prompt[1][@fetchAudio] eq 'false'" target="PlayingPrompt"/>

     <transition event="Play" cond="/datamodel/data[@name='[queue']/prompt[1][@fetchAudio] eq 'true'" target="FetchAudio"/>
    </state>

    <state id="PlayingPrompt">
     <datamodel>
      <data name="currentPrompt"/>
     </datamodel>
     <onentry>
      <assign loc="/datamodel/data[@name='currentPrompt']/prompt" val="/datamodel/data[@name='queue']/prompt[1])"/>
      <delete loc="/datamodel/data[@name='queue']/prompt[1]"/>
      <if cond="/datamodel/data[@name='currentPrompt']/prompt[@bargeInType] != /datamodel/data[@name='bargeInType']">
       <send event="BargeInChange" namelist="/datamodel/ data[@name='currentPrompt']/prompt[@bargeInType]"/>
       <assign loc="/datamodel/data[@name='bargeInType']" expr="/ datamodel/data[@name='currentPrompt']/prompt[@bargeInType]"/>
      </if>
     </onentry>

     <invoke targettype="player" srcexpr="/datamodel/ data[@name='currentPrompt']/prompt"/>

     <finalize>
       <if cond="_eventData/MarkTime neq '-1'">
         <assign name="/datamodel/data[@name='markName']/" val="_eventData/markName.text()"/>
         <assign name="/datamodel/data[@name='markTime']/" val="_eventData/markTime.text()"/>
       </if>
     </finalize>

     <transition event="player.Done" cond="/datamodel/data[@name='queue']/prompt[last()] le '1'" target="Idle">
      <send event="PlayDone" namelist="/datamodel/data[@name='markName'].text(), /datamodel/data[@name='markTime'].text()"/>
     </transition>

     <transition event="player.Done" cond="/datamodel/data[@name='queue'/prompt[1][@fetchAudio] neq 'true'" target="PlayingPrompt"/>

     <transition event="player.Done"
         cond="/datamodel/data[@name='queue']/prompt[1][@fetchAudio] eq 'true'" target="FetchAudio"/>

    </state> <!-- end PlayingPrompt -->

    <state id="FetchAudio">
      <initial id="WaitFetchAudio"/>

      <transition event="player.Done" target="FetchAudioFinal"/>

      <state id="WaitFetchAudio">
        <onentry>
          <send target="self" event="fetchAudioDelay"
          delay="/datamodel/data[@name='queue']/prompts[1][@fetchaudiodelay]"/>
        </onentry>

       <transition event="fetchAudioDelay" next="StartFetchAudio"/>
       <transition event="cancelFetchAudio" next="FetchAudioFinal"/>
      </state>

     <state id="StartFetchAudio">
      <datamodel>
       <data name="fetchAudio"/>
      </datamodel>
      <onentry>
       <assign loc="/datamodel/data[@name='fetchAudio']" expr="/datamodel/data[@name='queue']/prompts[1]"/>
       <delete loc="/datamodel/data[@name='queue']/prompts[1]"/>
       <send target="self" event="fetchAudioMin" delay="/datamodel/data[@name='fetchAudio'][@fetchaudiominimum]"/>
       <send target="player" event="Play" namelist="/datamodel/data[@name='fetchAudio']"/>
       <if cond="/datamodel/data[@name='bargeInType'].text() ne 'fetchAudio'">
         <send event="BargeInChange" namelist="fetchAudio"/>
       </if>
      </onentry>

      <transition event="CancelFetchAudio" target="WaitFetchMinimum"/>

      <transition event="fetchAudioMin" target="WaitFetchCancel"/>
     </state>

     <state id="WaitFetchMinimum">
       <transition event="fetchAudioMin" target="FetchAudioFinal">
         <send target="player" event="halt"/>
       </transition>
     </state>

     <state id="WaitFetchCancel">
       <transition event="CancelFetchAudio" target="FetchAudioFinal">
         <send target="player" event="halt"/>
       </transition>
     </state>

     <state id="FetchAudioFinal" final="true" />
     <!-- could put cleanup handling here -->

    </state> <!-- end FetchAudio -->
   </state> <!-- end Created -->
</scxml>

5.2.3 Defined Events

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

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

5.2.4 Device Events

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

and sends the following events to the underlying device:

5.2.5 Open Issue

5.3.1 Definition

The recognition resource is defined 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) ncan 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 by receiving further 'listen' and 'suspend' events. 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.

5.3.2 Defined Events

A recognition resource is defined by the events it receives:

and the events it sends:

5.3.3 Device Events

The resource receives from the recognition device the following events:

and sends to the recognition device the following events:

5.3.4 State Chart Representation

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

5.3.5 SCXML Representation

<?xml version="1.0" encoding="UTF-8"?>

<scxml initialstate="Created">
  <datamodel>
    <data name="activeGrammars"/>
    <data name="properties"/>
    <data name="controller"/>
    <data name="mode"/>
  </datamodel>
  <state id="Created">
    <initial id="idle"/>

    <state id="idle">
      <onentry>
        <foreach var="node" nodeset="datamodel/data[@name='activeGrammars']">
          <delete loc="$node"/>
        </foreach>
        <assign loc="/datamodel/data[@name='properties']" val="null"/>
        <assign loc="/datamodel/data[@name='controller']" val="null"/>
        <assign loc="/datamodel/data[@name='mode']" val="voice"/>
      </onentry>

      <transition event="AddGrammar">
        <datamodel>
          <data name = "gram"/>
        </datamodel>
        <assign name="/datamodel/data/[@name='gram']/grammar" expr="_eventData/grammar" />
        <assign name="/datamodel/data/[@name='gram']/properties" expr="_eventData/properties" />
        <assign name="/datamodel/data/[@name='gram']/listener" expr="_eventData/listener" />
        <insert pos="after" name="datamodel/data[@name='activeGrammars']" val="gram"/>
      </transition>

      <transition event="prepare" target="preparingGrammars">
        <assign loc="/datamodel/data[@name='properties']" expr="_eventData/properties"/>
        <assign loc="/datamodel/data[@name='controller']" expr="_eventData/controller"/>
      </transition>

    </state>    <!-- end idle -->

    <state id="preparingGrammars">
      <onentry>
        <if cond="isEmpty(/datamodel/data[@name='activeGrammars']) eq 'false'">
          <send target="device" event="dev:clear"/>
          <send target="device" event="dev:prepare" namelist="/datamodel/data[@name='activeGrammars'], /datamodel/data[@name='properties']"/>
        </if>
      </onentry>

      <transition cond="isEmpty(/datamodel/data[@name='activeGrammars']) eq 'true'" target="idle">
        <send target="controller" event="notPrepared"/>
      </transition>

      <transition event="stop" target="idle">
        <send target="device" event="dev:stop"/>
      </transition>

      <transition event="dev:prepared" target="readyToRecognize">
        <send target="controller" event="Prepared"/>
      </transition>

    </state>    <!-- end preparingGrammars -->

    <state id="readyToRecognize">
      <transition event="listen" target="recognizing" />

      <transition event="stop" target="idle">
        <send target="device" event="dev:stop"/>
      </transition>
    </state>    <!-- end readyToRecognize -->

    <state id="recognizing">
      <onentry>
        <send target="device" event="dev:listen"/>
      </onentry>

      <transition event="suspend" target="suspendedRecognizing"/>

      <transition event="dev:inputStarted" target="waitingForResult"/>

      <transition event="stop" target="idle">
        <send target="device" event="dev:stop"/>
      </transition>
    </state>    <!-- end recognizing -->

    <state id="suspendedRecognizing">
      <onentry>
        <send target="device" event="dev:suspend"/>
      </onentry>

      <transition event="listen" target="recognizing"/>

      <transition event="stop" target="idle">
        <send target="device" event="dev:stop"/>
      </transition>
    </state>    <!-- end suspendedRecognizing -->

    <state id="waitingForResult">
      <onentry>
        <send target="controller" event="inputStarted"/>
      </onentry>

      <transition event="dev:inputFinished">
        <send target="controller" event="inputFinished"/>
      </transition>

      <transition event="dev:partialResult">
        <send target="controller" event="partialResult" namelist="_eventData/results,_eventData/grammar/listener"/>
      </transition>

      <transition event="dev:recoResults" target="readyToRecognize">
        <send target="controller" event="recoResult" namelist="_eventData/results,_eventData/grammar/listener"/>
      </transition>

      <transition event="dev:error" target="idle">
        <send target="controller" event="error" namelist="_eventData/error status"/>
      </transition>

      <transition event="stop" target="idle">
        <send target="device" event="dev:stop"/>
      </transition>
    </state>    <!-- end waitForResult -->

  </state>  <!-- end Created -->

</scxml>

5.5.1 Definition

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

5.5.2 Final Processing State

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.

5.5.3 Defined Events

5.5.4 State Chart Representation

[TBD]

5.5.5 SCXML Representation

[TBD]

5.6.1 Definition

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.

5.6.2 Defined Events

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.

5.6.3 Device Events

The resource receives from the timer device the following events:

and sends to the timer device the following events:

5.6.4 State Chart Representation

TBD

6.1.1 Syntax

[See XXX for schema definitions].

6.1.2 Semantics

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

<?xml version="1.0" encoding="UTF-8"?>

<scxml initialstate="Created">
  <datamodel>
    <data id="controller"/>
    <data id="child"/>
    <data id="content"/> <!-- not used -->
    <data id="properties"/>
    <data id="mode"/>
    <data id="fetchhint"/>
  </datamodel>

  <state id="Created">
    <initial id="Idle"/>

    <state id="Idle">
      <onentry>
        <!-- ISSUE: Is this needed? -->
        <assign location="$controller" expr="null"/>
        <assign location="$child" expr="null"/>
        <assign location="$content" expr="null"/>
        <assign location="$properties/weight" expr="1.0"/>
        <assign location="$properties/fetchtimeout"/>
        <assign location="$properties/maxage"/>
        <assign location="$properties/maxstale"/>
        <assign location="$properties/charset"/>
        <assign location="$properties/encoding"/>
        <assign location="$properties/language"/>
        <assign location="$mode"/>
        <assign location="$fetchhint"/>
      </onentry>

      <transition event="initialize" target="Initializing">
        <assign name="$controller" expr="_eventData/controller"/>
        <assign name="$child" expr="_eventData/child"/>
      </transition>

    </state>    <!-- end Idle -->

    <state id="Initializing">

      <onentry>
        <!-- ISSUE: complete the initialization -->
        <assign location="$properties/weight" expr="1.0"/>
        <assign location="$properties/fetchtimeout" expr="InitDefault();"/>
        <assign location="$properties/maxage" expr="InitDefault();"/>
        <assign location="$properties/maxstale" expr="InitDefault();"/>
        <assign location="$properties/charset" expr="InitDefault();"/>
        <assign location="$properties/encoding" expr="InitDefault();"/>
        <assign location="$properties/language" expr="InitDefault();"/>
        <assign location="$mode" expr="InitDefault();"/>
        <assign location="$fetchhint" expr="InitDefault();"/>

        <send target="$child/controller" event="initialize"
          namelist="$child"/>
      </onentry>

      <transition event="Initializing.error" target="Idle">
        <send target="controller" event="initialize.error"
           namelist="_eventData/error_status"/>
      </transition>

      <transition event="Initializing.done" target="Ready">
        <if cond="$fetchhint eq 'prefetch'">
           <if cond="$mode eq 'voice'">
              <send target="ASRRecognizer" event="Prefetch"
                 namelist="$child $properties/fetchtimeout 
                           $properties/maxage $properties/maxstale"/>
           <else/>
              <send target="DTMFRecognizer" event="Prefetch"
                 namelist="$child $properties/fetchtimeout 
                           $properties/maxage $properties/maxstale"/>
           </if>
        </if>
        <send target="controller" event="initialized"/>
      </transition>

    </state>    <!-- end Initializing -->

    <state id="Ready">

      <transition event="execute" target="Executing"/>

    </state>    <!-- end Ready -->

    <state id="Executing">

      <onentry>
        <!-- ISSUE: Initialization function to be completed -->
        <assign location="$properties/fetchtimeout" expr="InitDefault();"/>
        <assign location="$properties/maxage" expr="InitDefault();"/>
        <assign location="$properties/maxstale" expr="InitDefault();"/>

    <!-- ISSUE: Add condition if $child is externalgrammar element -->
        <if cond="???">
          <send target="$child/controller" event="execute"
             namelist="$child"/>
        <else/>
           <!-- ISSUE: Missing in sendcontroller RC (e.g. link, field, etc) 
                as the handler for recognition results  -->
           <if cond="$mode eq 'voice'">
              <send target="ASRRecognizer" event="AddGrammar"
                 namelist="$child $fetchhint $properties/language
                           $properties/charset $properties/encoding"/>
           <else/>
              <send target="DTMFRecognizer" event="AddGrammar"
                 namelist="$child $fetchhint $properties/language
                           $properties/charset $properties/encoding"/>
           </if>
           <send target="controller" event="executed"/>
        </if>
      </onentry>

      <transition event="Executing.done">
         <!-- ISSUE: Missing in send controller RC (e.g. link, field, etc) 
              as the handler for recognition results  -->
         <if cond="$mode eq 'voice'">
            <send target="ASRRecognizer" event="AddGrammar"
               namelist="$child $fetchhint $properties/language
                         $properties/charset $properties/encoding"/>
         <else/>
            <send target="DTMFRecognizer" event="AddGrammar"
               namelist="$child $fetchhint $properties/language
                         $properties/charset $properties/encoding"/>
         </if>
         <send target="controller" event="executed"/>
      </transition>

    </state>    <!-- end Executing -->

  </state>
  <!-- end Created -->

</scxml>

6.1.3 Events

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.

6.1.4 Examples

[TBD: put all examples here.]

6.2.1 Syntax

[See XXX for schema definitions].

The syntax of the Inline SRGS Grammar Module is precisely all of the XML markup for a legal stand-alone XML form grammar as described in SRGS ([SRGS]), minus the XML Prolog. Note that both elements and attributes must be in the SRGS namespace (http://www.w3.org/2001/06/grammar).

6.2.2 Semantics

6.2.3 Events

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.

6.2.4 Examples

[TBD: put all examples here.]

6.3.1 Syntax

[See XXX for schema definitions].

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.

6.3.2 Semantics

6.3.3 Events

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

6.3.4 Examples

[TBD: put all examples here.]

6.4.1 Syntax

[See XXX for schema definitions].

6.4.2 Semantics

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

6.4.2.4 State Chart Representation

Figure 10: Prompt RC States

<?xml version="1.0" encoding="UTF-8"?>

<scxml initialstate="Created">
  <datamodel>
    <data id="properties"/>
    <data id="children"/>
    <data id="content"/>
    <data id="properties"/>
    <data id="count"/>
    <data id="cond"/>
    <data id="xml:lang"/>
    <data id="xml:base"/>
  </datamodel>

  <state id="Created">
    <initial id="Idle"/>

    <state id="Idle">
      <onentry>
        <assign location="$controller" expr="null"/>
        <assign location="$children" expr="null"/>
        <assign location="$content" expr="null"/>
        <assign location="$properties/bargein" expr="true"/>
        <assign location="$properties/bargeintype" expr="speech"/>
        <assign location="$properties/timeout" expr="5s"/>
        <assign location="$count" expr="1"/>
        <assign location="$cond" expr="true"/>
        <assign location="$xml:lang" expr=""/>
        <assign location="$xml:base" expr=""/>
      </onentry>

      <transition event="initialize" target="Initializing">
        <assign name="$controller" expr="_eventData/controller"/>
        <assign name="$children" expr="_eventData/children"/>
      </transition>

    </state>    <!-- end Idle -->

    <state id="Initializing">

      <datamodel>
        <data id="childcounter"/>
      </datamodel>

      <onentry>
        <assign location="$childcounter" expr="0"/>
        <foreach var="child" array="$children">
          <send target="$child/controller" event="initialize"
          namelist="$child/child"/>
        </foreach>
      </onentry>

      <transition event="Initializing.done">
        <assign location="$childcounter" expr="$childcounter + 1"/>
      </transition>

      <transition event="Initializing.error" target="Idle">
        <assign location="$childcounter" expr="$childcounter + 1"/>
        <send target="controller" event="initialize.error"
        namelist="_eventData/error_status"/>
      </transition>

      <transition event="Initializing.done" cond="$childcounter eq
      $children.size()-1" target="Ready">
        <send target="controller" event="initialized"/>
      </transition>

    </state>    <!-- end Initializing -->

    <state id="Ready">
      <datamodel>
        <data id="status"/>
      </datamodel>

      <transition event="checkStatus" target="FormReady">
        <assign location="$status" expr="checkStatus()"/>
        <send target="controller" event="checkStatus"
        namelist="$status, $count"/>
      </transition>

      <transition event="execute" cond="checkStatus() eq 'true'"
      target="Executing"/>

      <transition event="execute" cond="checkStatus() eq 'false'">
        <send target="controller" event="executed"/>
      </transition>
    </state>    <!-- end Ready -->

    <state id="FormReady">
      <datamodel>
        <data id="status"/>
      </datamodel>

      <transition event="checkStatus">
        <assign location="$status" expr="checkStatus()"/>
        <send target="controller" event="checkStatus"
        namelist="$status, $count"/>
      </transition>

      <transition event="execute" target="Executing"/>
    </state>    <!-- end FormReady -->

    <state id="Executing">

      <datamodel>
        <data id = "prompt"/>
      </datamodel>
      <onentry>
        <assign location="$counter" expr="0"/>
        <assign location="$child_return" expr="null"/>

        <foreach var="child" array="$children">
          <send target="$child/controller" event="evaluateChild"/>
        </foreach>
      </onentry>

      <transition event="Executing.done">
        <assign location="$counter" expr="$counter + 1"/>
        <insert pos="after" name="$prompt" expr="_eventData/prompts"/>
      </transition>

      <transition event="Executing.error" target="Idle">
        <send target="controller" event="Executing.error"
        namelist="_eventData/error_status"/>
      </transition>

      <transition event="Executing.done" cond="$counter eq
      $children.size()-1" target="Ready">
        <insert pos="after" name="$prompt" expr="_eventData/prompts"/>
        <send target="PromptQueue" event="/queuePrompt"
        namelist="$prompt, $properties"/>
        <send target="controller" event="executed"/>
      </transition>

    </state>    <!-- end Executing -->

  </state>
  <!-- end Created -->

</scxml>

6.4.3 Events

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

6.4.4 Examples

[TBD: put all examples here.]

6.5.1 Syntax

[See XXX for schema definitions].

This module defines an SSML ([SSML]) Conforming Speech Synthesis Markup Language Fragment where:

• there is no explicit <speak> element.
• these elements are part of the VoiceXML namespace rather than the SSML namespace
• the <foreach> element may appear inside these elements prior to evaluation
• the <value> element may appear inside these elements prior to evaluation
• The <audio> element is extended with the attributes specified in Table 33.

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

6.5.2 Semantics

When the RC receives an evaluate event, its children are evaluated in order to return an SSML Conforming Stand-Alone Speech Synthesis Markup Language Document which can be processed by a Conforming Speech Synthesis Markup Language Processor.

Evaluation comprises of:

• data model expressions are evaluated against the data model.
• If a <foreach> element is present, it is evaluated so as to yield content for each defined item in the array.
• If an <audio> element has a specified expr attribute, then the attribute value is evaluated to provide a URI value for the src attribute. If the expr evaluation results in an ECMAScript undefined value, then the <audio> element, including its alternate content, is ignored.
• If a <value> element is present, its expr attribute is evaluated to return a CDATA value.
• construction of a <speak> element with appropriate version, namespace, and xml:lang attributes. The xml:lang attribute value is inherited from the <prompt> element (see 6.4 Prompt Module).
• if an unsupported language is encountered, the platform throws an error.unsupported.language event which specifies the language in its message variable

6.5.3 Examples

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.

6.6.1 Syntax

[See XXX for schema definitions].

6.6.2 Semantics

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

6.6.3 Examples

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>

6.7.1 Syntax

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)

6.7.2 Semantics

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.

6.7.3 Examples

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>

6.8.1 Syntax

[See XXX for schema definitions].

6.8.2 Semantics

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

6.8.3 Examples

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>

6.9.1 Syntax

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.

6.9.2 Semantics

6.9.2.1 Form RC

The Form RC is the primary RC for the <form> element.

The Form RC interacts with resource controllers of other modules so as to provide the behavior of VoiceXML 2.1/2.0 <form> tag. Input and control form items are modeled as resource controllers: for the example, the <field> RC (6.10.2.1 Field RC) of the Field Module.

The behavior of the Form RC follows the VoiceXML FIA, although some aspects of this are not modeled directly in this RC: external transition handling is not part of the form RC; input items used separate RCs to manage coordination between media resources, while recognition results can be received directly by form, field or other RCs.

[This initial version does not address all aspects of FIA behavior; for example, event handling, error handling and external transitions are not covered.]

6.9.2.1.1 Definition

The form RC is defined in terms of a data model and state model.

The data model is composed of the following parameters:

• controller: the RC controlling this form RC
• children: array of children's (primary) RC
• activeItem: current form item being executed
• active: Boolean indicating whether this form is active. Default: false.
• justFilled: array of child RC which have just been filled
• recoResult: The recognition result of the previously executed form item.
• previousItem: The previous form item already executed.
• nextItem: The next form item which is presently scheduled for executed.
• modal: The modality of the current form item being executed.
• id: The form identifier.

The form RC's state model consists of the following states: Idle, Initializing, Ready, SelectingItem, PreparingItem, PreparingFormGrammars, PreparingOtherGrammars, Executing, Active, ProcessingFormResult, Evaluating and Exit.

In the Idle state, the form RC can receive an 'initialize' event whose 'controller' event data is used to update the data model. The RC then transitions into Initiating state.

In the Initializing state, the RC creates a dialog scope in the Datamodel Resource and then initializes its children: this is modeled as a separate RC. When all children are initialized, the RC sends an 'initialized' event to its controller and transitions to the Ready state.

In the Ready state, the form RC sets its active status to false. It can receive one of two events: 'prepareGrammars' or ‘execute’. ‘prepareGrammars’ indicates that another form is active, but this form's form-level grammars may be activated; an 'execute' event indicates that this form is active. If the RC receives a 'prepareGrammars' event, it transitions to the PreparingFormGrammars state. If the RC receives an 'execute' event, it sets its active data to true and transitions to the 'SelectingItem' state.

In the SelectingItem state, the RC determines which form item to select as the active item. This is defined by a FormItemSelection RC which iterates over the children sending each a 'checkStatus' event. If a child returns a true status (indicating that it ready for execution)), the activeItem is set to this child RC and the RC transitions to the PreparingItem state. If no child returns this status, then the RC is complete and transitions the Exit State.

In the PreparingItem state, the activeItem is sent a 'prepare' event causing it to prepare itself; for example, the field RC prepares its prompts and grammars for execution. When the activeItem returns a 'prepared' event, the event data indicates whether the item is modal or not. If the item is modal, then the form RC transitions to the Executing state. If the item is not modal (other grammars can be activated), then the form RC transitions to the PreparingFormGrammars state.

In the PreparingFormGrammars state, the RC prepares form-level grammars. This is defined by a separate RC which iterates through and executes grammar children. When this is complete, the RC transitions to the Active state if the form is not active (active data), and transitions to the PreparingOtherGrammars if the form is active.

In the PreparingOtherGrammars states, the RC sends a 'prepareGrammars' event to its controller RC (which in turn sends the event to appropriate form, document and application level RCs with grammars). When its receives a 'prepared' from its controller, the RC transitions to the Executing state.

In the Executing state, the form RC sends an 'execute' event to the active form item. If the form item is a field, then this will causes prompts to be played and recognition to take place. The RC then transitions to the Active state awaiting a result.

In the Active state, the RC re-initializes the justFilled data to a new array and waits for a recognition results (as active or non-active form), or for a signal from its selected form item that it has received the recognition result. Recognition results are divided into two types: form item level results, received and processed by the form item; and form level results which are received by the form RC which caused the grammar to be added. If a 'recoResult' event is received by the form RC, the RC transitions into the ProcessingFormResult state. If the active form item receives the recognition result (and locally updated itself), then the form RC receives a 'formItemResult' event, adds the active item to the justFilled array, and transitions into the Evaluating state.

In the ProcessingFormResult state, the recognition result is processed by iterating through the form item children, obtaining their name and slotname, and then attempting to match the slotname to the results. If the match is successful, the name variable in the data model result is updated with the value from the recognition result and the child is added to the justFilled data array. When this process is complete, the form RC transitions to the Evaluating state.

In the Evaluating state, the form RC then iterates through its children and if a child is a member of the 'JustFilled' array, it sends a 'evaluate' event to the form item RC causing the appropriate filled RCs to be executed. If the child is a filled RC, then it is executed if appropriate. When evaluation is complete, the form RC transitions to the 'selectformitem' state so that the next form item can be selected for execution.

6.9.2.1.2 Defined Events

Table 38: Table: Events received by <form> RC

Event	Source	Payload	Description
initialize	any	controller(M)	Update the data model
prepareGrammars	controller		Another form is active, but the current form's form-level grammars may be activated.
execute	controller		Current form is active

Table 39: Table: Events received by <form> RC

Event	Source	Payload	Description
initialize	controller		Notification that initialization is complete
prepareGrammars	controller		Sent to prepare grammars to appropriate form, document and application level RCs.
execute	controller		Notification of complete recognition result from the field RC.

6.9.2.1.3 External Events

The following table shows the events sent and received by the form RC to resources and other RCs which define the events.

Table 40: Table: <form> RC External Events

Event	Source	Target	Description
checkStatus	FormRC	FormItem RC	Check if ready for execution
createScope	FormRC	DataModel	Creates a scope.
destroyScope	FormRC	DataModel	Delete a scope.
evaluate	FormRC	FormItem RC	Process form item being filled.
execute	FormRC	FormItem RCs	Start execution.
prepare	FormRC	FormItem RC	Initiates preparation needed before execution.
formItemResult	FormItemRC	FormRC	Results received by the form item.
prepared	FormItemRC	FormRC	Indicates that preparation is complete.
recoResult	PlayAndRecognize RC	FormRC	Results filled at the form level and not form item level.

6.9.2.1.4 State Chart Representation

Figure 11: Form RC States

Editorial note
Note that the chart for SelectingItem:FormItemSelection is missing. It will be defined later.

6.9.2.1.5 SCXML Representation

<?xml version="1.0" encoding="UTF-8"?>

<scxml initialstate="Created">
  <datamodel>
    <data id="controller"/>
    <data id="children"/>
    <data id="activeItem"/>
    <data id="active"/>
    <data id="previousItem"/>
    <data id="nextItem"/>
<data id="recoResult"/>
    <data id="name"/>
    <data id="JustFilled"/>
  </datamodel>

  <state id="Created">
    <initial id="Idle"/>

    <state id="Idle">
      <onentry>
        <assign loc="$controller" val="null"/>
        <assign loc="$children" val="null"/>
        <assign loc="$activeItem" val="null"/>
        <assign loc="$active" val="false"/>
        <assign loc="$previousItem" val="null"/>
        <assign loc="$nextItem" val="null"/>
        <assign loc="$recoResult" val="null"/>
        <assign loc="$name" val="null"/>
      </onentry>

      <transition event="initialize" target="Initializing">
        <assign name="$controller" expr="_eventData/controller"/>
      </transition>

    </state>    <!-- end Idle -->

    <state id="Initializing">
      <datamodel>
        <data id="childcounter"/>
      </datamodel>

      <onentry>
        <assign loc="$childcounter" val="0"/>
        <send target="datamodel" event="createScope" namelist="dialog"/>
        <foreach var="child" array="$children">
          <send target="$child/controller" event="initialize" namelist="$child/child"/>
        </foreach>
      </onentry>


      <transition event="Initializing.done">
        <assign loc="$childcounter" expr="$childcounter + 1"/>
      </transition>

      <transition event="Initializing.error">
        <assign loc="$childcounter" expr="$childcounter + 1"/>
        <send target="controller" event="initialize.error" namelist="_eventData/error_status"/>
      </transition>

      <transition event="Initializing.done" cond="$childcounter eq $children.size()-1" target="Ready">
        <send target="controller" event="initialized"/>
      </transition>

    </state>    <!-- end Initializing -->

    <state id="Ready">
      <onentry>
        <assign loc="$active" val="false"/>
      </onentry>

      <transition event="execute" target="SelectingItem:FormItemSelection">
        <assign loc="$active" value="true"/>
      </transition>

      <transition event="prepareGrammars" target="PreparingFormGrammars"/>
    </state>    <!-- end Ready -->

    <state id="SelectingItem:FormItemSelection">

      <onentry>
        <send target="FormItemSelection" event="checkStatus" namelist="$children"/>
      </onentry>

      <transition event="SelectedFormItem.done" cond="activeItem eq 'null'" target="Exit"/>

      <transition event="SelectedFormItem.done" cond="activeItem neq 'null'" target="PreparingItem"/>
    </state>    <!-- end SelectingItem:FormItemSelection -->

    <state id="PreparingItem">
      <onentry>
        <send target="activeitem" event="prepare" />
      </onentry>

      <transition event="prepared" cond="_eventData/modal eq 'true'" target="Executing"/>

      <transition event="prepared" cond="_eventData/modal eq 'false'" target="PreparingFormGrammars"/>
    </state>    <!-- end PreparingItem-->

    <state id="Exit">
      <onentry>
        <send target="datamodel" event="destroyScope" namelist="dialog"/>
        <send target="parent" event="done"/>
      </onentry>
    </state>    <!-- end Exit-->

    <state id="PreparingFormGrammars">
      <transition event="PrepareFormGrammars.done" cond="active eq 'true'" target="PreparingOtherGrammars"/>

      <transition event="PrepareFormGrammars.done" cond="active eq 'false'" target="PreparingOtherGrammars">
        <send target="controller" event="prepared"/>
      </transition>
    </state>    <!-- end PreparingFormGrammars -->

    <state id="PreparingOtherGrammars">
      <onentry>
        <send target="controller" event="prepareGrammars"/>
      </onentry>

      <transition event="PrepareOtherGrammars.done" target="Executing"/>
    </state>    <!-- end PreparingOtherGrammars -->

    <state id="Executing">
      <onentry>
        <send target="activeItem" event="execute"/>
      </onentry>

      <transition event="Executing.done" target="Active"/>
    </state>    <!-- end Executing -->

    <state id="Active">
      <onentry>
        <assign loc="$JustFilled" expr="new Array()"/>
      </onentry>

      <transition event="fieldResult" target="Evaluating">
        <insert pos="after" name="$JustFilled" val="currentitem"/>
      </transition>

      <transition event="PlayAndRecognize:RecogResult" target="ProcessingFormResult">
        <insert pos="after" name="$JustFilled" val="currentitem"/>
      </transition>

    </state>    <!-- end Active -->

    <state id="ProcessingFormResult">

      <onentry>
          <foreach var="child" array="$children">
           <if cond="$child.slotname eq _eventData/RecogResult/slotname">
                       <assign loc="$name" value="_eventData/RecogResult/name"/>
                       <insert pos="after" name="$JustFilled" val="$child"/>
                       <transition target="Evaluating"/>
           </if>
        </foreach>

      </onentry>

      <transition event="ProcessingFormResult.done" target="Evaluating"/>
    </state>    <!-- end ProcessingFormResult -->

    <state id="Evaluating">
      <onentry>
        <send target="activeItem" event="evaluate"/>
      </onentry>

      <transition event="Evaluating.done" target="SelectingItem:FormItemSelection"/>
    </state>    <!-- end Executing -->

  </state>  <!-- end Created -->

</scxml>

6.10.1 Syntax

6.10.2 Semantics

The semantics of field elements are defined using the following resource controllers: Field (6.10.2.1 Field RC), PlayandRecognize (6.10.2.2 PlayandRecognize RC), ...

6.10.2.1 Field RC

The Field Resource Controller is the primary RC for the field element.

6.10.2.1.1 Definition

The field RC is defined in terms of a data model and state model.

The data model is composed of the following parameters:

• controller: the RC controlling this field RC
• children: array of children's (primary) RC
• includePrompts: boolean indicating whether prompts are to be played. Default: true.
• counter: prompt counter. Default: 1.
• recoResult: ??
• name:
• expr:
• cond:
• modal:
• slot:

The field RC's state model consists of the following states: Idle, Initializing, Ready, Preparing, Prepared, Executing and Evaluating.

While in the Idle state, the RC may receive an 'initialize' event, whose 'controller' event data is used to update the data model. The RC then transitions into Initiating state.

In the Initializing state, the RC creates a variable in the Datamodel Resource: the variable name corresponds to the name in the RC's data model, and the variable value is set to the value of the RC's data model expr, if this is defined. The field RC then initializes its children: this is modeled as a separate RC (see XXX). When all children are initialized, the RC transitions to the Ready state.

In the Ready state, the field RC can receive an 'checkStatus' event to check whether it can be executed or not. The value of name and cond in its data model are checked: the status is true if the name is undefined and the value of cond evaluates to true. The status is returned in a 'checkedStatus' event sent back to the controller RC. If the RC receives a 'prepare' event, it updates includePrompts in its data model using the event data, and transitions to the Preparing state.

In the Preparing state, the field prepares its prompts and grammars. Prompts are prepared only if the includePrompts data is true; otherwise, prompts within the field are not prepared (e.g. field prompts aren't queued following a <reprompt>). Preparation of prompts is modeled as a separate RC (see XXX), as is preparation of grammars (see YYY). These RCs are summarized below.

Prompts are prepared by iterating through the children array. In the iteration, each prompt RC child is sent a 'checkStatus' event. If the prompt child returns true (its cond parameter evaluates to true), then it is added to a 'correct count' list together with its count. Once the iteration is complete, the RC determines the highest count on the 'correct count' list: the highest count among those on the list less than or equal to the current count value. All child on the 'correct count' list whose count is not the highest count are removed. The RC then iterates through the 'correct count' list and sends an 'execute' event to each prompt RC, causing it to be queued on the PromptQueue Resource.

Grammars are prepared by recursing through the children array and sending each grammar RC child an 'execute' event. The grammar RC then, if appropriate, sends an 'addGrammar' event to the DTMF or ASR Recognizer Resource where the grammar itself, its properties and the field RC is sent as the handler for recognition results.

When prompts and grammars have been prepared, the prompt counter is incremented and the field RC sends a 'prepared' event to its controller with event data indicating its modal status and then transition into the Prepared state.

In the Prepared state, the field RC may receive an 'execute' event from its controller. The RC sends an 'execute' event to the PlayAndRecognize RC (6.10.2.2 PlayandRecognize RC), causing any queued prompts to be played and recognition to be initiated. In the event data, the controller is set to this RC, and other data is derived from data model properties. The RC transitions to the Executing state.

In the Executing state, the PlayAndRecognize RC must send recoResults (or error events: noinput, nomatch, error.semantic) to the field RC.

If the field RC receives the recoResults, then it updates its name variable in the Datamodel Resource. The field RC then sends a 'fieldResult' event to its controller indicating that a field result has been received and processed.

If the recoResult is received by the field RC's controller, then the field receives an 'evaluate' event which causes it to transition to the Evaluating state.

In the Evaluating state, the field RC iterates through its children executing each filled RC: this is modeled by a separate RC (see XXX). When evaluation is complete, the RC sends a 'evaluated' event to its controller and transitions to the Ready state.

6.10.2.1.2 Defined Events

The Field RC is defined to receive the following events:

Table 42: Events received by Field RC

Event	Source	Payload	Description
initialize	any	controller(M)
checkStatus	controller
prepare	controller	includePrompts (M)
execute	controller
evaluate	controller

and the events it sends:

Table 43: Events sent by Field RC

Event	Target	Payload	Description
initialized	controller
checkedStatus	controller
prepared	controller
fieldResult	controller
evaluated	controller

6.10.2.1.3 External Events

Table 44 shows the events sent and received by the field RC to resources and other RCs which define the events.

Table 44: Field RC External Events

Event	Source	Target	Description
create	FieldRC	DataModel
assign	FieldRC	DataModel
execute	FieldRC	PlayandRecognizeRC
recoResult	PlayandRecognizeRC	FieldRC

6.10.2.1.4 State Chart Representation

Figure 12: Field RC States

6.10.2.1.5 SCXML Representation

<?xml version="1.0" encoding="UTF-8"?>

<scxml initialstate="Created">
  <datamodel>
    <data id="controller"/>
    <data id="children"/>
    <data id="counter"/>
    <data id="recoResult"/>
    <data id="cond"/>
    <data id="name"/>
    <data id="expr"/>
    <data id="modal"/>
    <data id="includePrompts"/>
  </datamodel>

  <state id="Created">
    <initial id="Idle"/>

    <state id="Idle">
      <onentry>
        <assign location="$controller" val="null"/>
        <assign location="$children" expr="new Array()"/>
        <assign location="$counter" val="1"/>
        <assign location="$recoResult" val="null"/>
        <assign location="$cond" val="null"/>
        <assign location="$expr" val="null"/>
        <assign location="$modal" val="false"/>
        <assign location="$includePrompts" val="true"/>
      </onentry>

      <transition event="initialize" target="Initializing">
        <assign name="$controller" expr="_eventData/controller"/>
      </transition>

    </state>
    <!-- end Idle -->

    <state id="Initializing">
      <datamodel>
        <data id="childcounter"/>
      </datamodel>

      <onentry>
        <if cond="expr neq 'null'">
          <send target="datamodel" event="assign" namelist="$name, $expr"/>
          <else>
            <send target="datamodel" event="create" namelist="$name"/>
          </else>
        </if>

        <assign location="$childcounter" val="0"/>
        <foreach var="child" array="$children">
          <send target="$child/controller" event="initialize"/>
        </foreach>
      </onentry>


      <transition event="Initializing.done">
        <assign location="$childcounter" expr="$childcounter + 1"/>
      </transition>

      <transition event="Initializing.error">
        <assign location="$childcounter" expr="$childcounter + 1"/>
        <send target="controller" event="initialize.error" namelist="_eventData/error_status"/>
      </transition>

      <transition event="Initializing.done" cond="$childcounter eq $children.size()-1" target="Ready">
        <send target="controller" event="initialized"/>
      </transition>

    </state>
    <!-- end Initializing -->

    <state id="Ready">

      <transition event="checkStatus" >
        <assign location="$status" expr="checkStatus()"/>
        <send target="controller" event="checkedStatus" namelist="_eventData/status"/>
      </transition>

      <transition event="prepare" target="Preparing">
        <assign location="$includePrompts" expr="_eventData/includePrompts"/>
      </transition>
    </state>
    <!-- end Ready -->

    <state id="Preparing">
      <onentry>
        <if cond="$includePrompts eq 'true'">
          <send target="Prompts RC" event="initialize"/>
        </if>
        <send target="Grammars RC" event="initialize"/>
      </onentry>

      <transition event="preparing.done" target="Prepared">
        <send target="controller" event="prepared" namelist="modal"/>
      </transition>

    </state>
    <!-- end Preparing -->

    <state id="Prepared">
      <transition event="execute" target="Executing">
        <send target="PlayAndRecognize" event="execute" namlist="self, inputmodes"/>
      </transition>
    </state>
    <!-- end Prepared-->

    <state id="Executing">
      <datamodel>
        <data id="value"/>
      </datamodel>
      <transition event="playAndReco:recoResult">
        <assign location="$value" expr="processResults($name, slot, _eventdata/result)"/>
        <send target="datamodel" event="assign" namelist="$name, $value"/>
        <send target="parent" event="fieldResult"/>
      </transition>
    </state>
    <!-- end Executing-->

    <state id="Evaluating">
      <onentry>
        <send target="filled RC" event="executeFilleds"/>
      </onentry>

      <transition event="evaluating.done" target="Ready">
        <send target="controller" event="evaluated"/>
      </transition>
    </state>
    <!-- end Evaluating-->

  </state>
  <!-- end Created -->

</scxml>

6.10.2.2 PlayandRecognize RC

The PlayandRecognize RC coordinates media input with Recognizer resources and media output with the PromptQueue Resource.

The following use cases are covered:

1. Bargein is not active and bargeintype is speech. Prompts are played to completion and the user provides positive input, negative input or no input.
2. Bargein is active and bargeintype is speech. Prompts are played to completion and the user provides positive input, negative input or no input.
3. Bargein is active and bargeintype is speech. User interrupts prompts and the user provides positive input, negative input or no input.
4. Bargein is not active and bargeintype is hotword. Prompts are played to completion and the user provides positive input, negative input or no input. User may provide a positive input after one or more negative inputs. The 'nomatch' event is never generated.
5. Bargein is active and bargeintype is hotword. User interrupts prompts and the user provides positive input, negative input or no input. User may provide a positive input after one or more negative inputs. The 'nomatch' event is never generated.
6. Prompt sequences alternating between bargein and no bargein.
7. Prompt sequences alternating between speech and hotword bargeintype.

Editorial note
Open issue: should we remove the possibility for alternating speech and hotword bargein modes within the recognition cycle?

6.10.2.2.1 Definition

The PlayandRecognize RC coordinates media input with recognition resources and media output with the PromptQueue Resource on behalf of a form item.

This RC activates prompt queue playback, activates recognition resources, manages bargein behavior and handles results from recognition resources.

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

The data model is composed of the following parameters:

• controller: the RC controlling this RC
• bargein: Boolean indicates whether bargein is active or not. Default: true.
• bargeintype: indicates the type of bargein, if active. Default: speech.
• inputmodes: active recognition input modes. Default: voice and dtmf.
• inputtimeout: timeout to wait for input. Default: 0s. (Required since the prompt queue may be empty).
• dtmfProps: DTMF properties
• asrProps: Speech recognition properties
• maxnbest: maximum number of nbest results. Default: 1.
• recoActive: boolean indicating whether recognition is active. Default: false.
• markname: string indicating current markname. Default: null
• marktime: time designator indicating current marktime. Default: 0s.
• recoResult:
• recoListener:
• activeGrammars: Boolean indicating whether grammars are active. Default: false.

The RC model consists of the following states: idle, prepare recognition resources, start playing, playing prompts with bargein, playing prompts without bargein, recognizing with a timer, waiting for input, waiting for speech result and update results. The complexity of this model is partially a consequence of supporting the relationship between hotword bargein and recognition result processing.

While in the idle state, the RC may receive an 'execute' event, whose event data is used to update the data model. The event information includes: controller, inputmodes, inputtimeout, dtmfProps, asrProps and maxnbest. The RC transition to the prepare recognition resources state.

In the prepare recognition resources, the RC sends 'prepare' events to the ASR and DTMF recognition resource. Both events specify this RC as the controller parameter, while the properties parameter differs. In this state, the RC can received 'prepared' or 'notPrepared' events from either recognition resources. If neither resource returns a 'prepared' event, then activeGrammars is false (i.e. no active DTMF or speech grammar) and the RC sends an 'error.semantic' event to the controller and exits. If at least one resource returns a 'prepared' event, then the RC moves into the start playing state.

The start playing state begins by sending the PromptQueue resource a 'play' event. The PromptQueue responds with a 'playDone' event if there are no prompt in the prompt queue; as a result, this RC moves into the start recognizing with timer state. If there is at least one prompts in the queue, the PromptQueue sends this RC a 'playStarted' event whose data contains the bargein and bargeintype values for the first prompt, and the input timeout value for the last prompt in the queue. The data model is updated with this information.

Editorial note
Open issue: PromptQueue Resource doesn't currently have playStarted event. If we don't add playStarted event, then is there a better way to get the bargein, bargeintype, and timeout information from the prompts in the PromptQueue?

Interaction with the recognizer during prompt playback is determined by the data model's bargein value. If bargein is true, then this RC transitions to the playing with bargein state. If bargein is false, the RC transitions to the playing without bargein state.

Editorial note

Open Issue: The event "bargeinChange" as a one way notification could pose a problem, as it takes finite time for recognizer to suspend or resume. This might work better if PromptQueue Resource waited for an event "bargeinChangeAck" (or similar) from PlayandRecognize RC before starting the next play. PlayandRecognize RC will send the event "bargeinChangeAck" after it completed suspend or resume action on the recognizer.

In the playing without bargein state, recognition is suspended if it has been previously activated (recoActive parameter of the data model tracks this). Suspending recognition is conditional on the value of 'inputmodes' data parameter; if 'dtmf' is in inputmodes, then DTMF recognition is suspended; if 'voice' is in inputmodes, the ASR recognition is suspended. In this state, the PromptQueue can report to this RC changes in bargein and bargeintype as prompts are played: a 'bargeintypeChange' event with the values 'hotword' or 'speech' cause the data model parameter 'bargein' to the set to 'true' and the 'bargeintype' parameter to be updated with event data value. If the PromptQueue resource sends a 'playDone' event, then the data model markname and marktime parameters are updated and the RC transitions to the start recognizing with timer state.

In the playing with bargein state, recognition is activated if it has not been previously activated (determined by recoActive parameter in the data model). Activating recognition is conditional on the value of 'inputmodes' data parameter; if 'dtmf' is in inputmodes, then DTMF recognition is activated; if 'voice' is in inputmodes, then ASR recognition is activated. In this state, the PromptQueue can report changes in bargein and bargeintype as prompts are played: a 'bargeintypeChange' event where the event data value is not 'unbargeable' causes the data model 'bargeintype' parameter to be updated with the event data ('hotword' or 'speech'); while a 'bargeintypeChange' where the event data value is 'unbargeable' causes the data model 'bargein' parameter to set to false and the RC transitions to the playing without bargein state. If the PromptQueue resources sends a 'playDone' event, then the data model markname and marktime parameters are updated and the RC transitions to the start recognizing with timer state.

Recognition handling in this state depends upon the bargeintype data parameter. If the bargeintype is 'speech' and a recognizer sends a 'inputStarted' event, then the RC transition to the waiting for speech result state. If the bargeintype is 'hotword', then recognition results are processed within this state. In particular, if a recognition resource sends a 'recoResults' event, then its event data is processed to determine if the recognition result is positive or negative.

Editorial note

Further details on recognition processing to be added in later versions. recoResults data parameter is updated with the recognition results (truncated to maxnbest). A speech result is positive iff there is at least one result whose confidence level is equal to or greater than the recognition confidence level; otherwise the result is negative. DTMF results are always positive. The recoListener data parameter is defined as the listener associated with the best result if the result is positive.

If positive, the RC sends the PromptQueue a 'halt' event, and transitions to the update results state. If negative, the RC sends a 'listen' event to the recognition resource which sent the 'recoResults' event.

In the start recognizing with timer state, an input timer is activated for the value of the inputtimeout data parameter and, if the recognition is not already active (determined by the recoActive data parameter). Recognition activation is conditional on the value of 'inputmodes' data parameter; if 'dtmf' is in inputmodes, then DTMF recognition is activated; if 'voice' is in inputmodes, the ASR recognition is activated. The RC then transitions into the waiting for input state.

In the waiting for input state, the RC waits for user input. If it receives a 'timerExpired' event, then the RC sends a 'stop' event to all recognition resources, sends a 'noinput' event to its controller and exits. Recognition handling in this state depends upon the bargeintype data parameter. If the bargeintype is 'speech' and a recognizer sends a 'inputStarted' event, then the RC transition to the waiting for speech result state. If the bargeintype is 'hotword', then recognition results are processed within this state. In particular, if a recognition resource sends a 'recoResults' event, then its event data is processed to determine if the recognition result is positive or negative. If positive, the RC cancels the timer, and transitions to the update results state. If negative, the RC sends a 'listen' event to the recognition resource which sent the 'recoResults' event.

In the waiting for speech result state, the RC waits for a 'recoResult' event whose data is used to update the recoResult data parameter and to set the recoListener data parameter if the recognition result is positive. The RC then transitions to the update results state.

In the update results state, the RC sends 'assign' events to the data model resource, so that the lastresult object in application scope is updated with recognition results as well as markname and marktime information. If the recoListener data parameter is defined, then the RC sends a 'recoResult' event to the recognition listener RC; otherwise, it sends 'nomatch' event to its controller. The RC then exits.

Editorial note

Open issue: Behavior if one reco resource sends 'inputStarted' but other sends 'recoResults'? Race conditions between recognizers returning results? (This problem is inherent to the presence of two recognizers. For the sake of clear semantics, we could restrict only one recognizer to respond with 'inputStarted' and 'recoResults'. The other recognizer is always 'stopped'. But a better choice might be to have only one recognizer that handles both DTMF and speech, since semantically both recognizers are very similar.)

6.10.2.2.2 Defined Events

The PlayandRecognize RC is defined to receive the following events:

Table 45: Events received by PlayandRecognize RC

Event	Source	Payload	Sequencing	Description
execute	any	controller(M), inputmodes (O), inputtimeout (O), dtmfProps (M), recoProps (M), maxnbest (O)

and the events it sends:

Table 46: Events sent by PlayandRecognize RC

Event	Target	Payload	Sequencing	Description
recoResult	any	results (M)	one-of: nomatch, noinput, error.*, recoResult
nomatch	controller		one-of: nomatch, noinput, error.*, recoResult
noinput	controller		one-of: nomatch, noinput, error.*, recoResult
error.semantic	controller		one-of: nomatch, noinput, error.*, recoResult
error.badfetch.grammar	controller		one-of: nomatch, noinput, error.*, recoResult
error.noresource	controller		one-of: nomatch, noinput, error.*, recoResult
error.unsupported.builtin	controller		one-of: nomatch, noinput, error.*, recoResult
error.unsupported.format	controller		one-of: nomatch, noinput, error.*, recoResult
error.unsupported.language	controller		one-of: nomatch, noinput, error.*, recoResult

6.10.2.2.3 External Events

The events in Table 47 are sent by the PlayandRecognize RC to resources which define the events.

Table 47: External Events send by PlayandRecognize RC

Event	Target	Payload	Sequencing	Description
play	PromptQueue
halt	PromptQueue
prepare	Recognizer
listen	Recognizer
suspend	Recognizer
stop	Recognizer

The events in Table 48 are received by this RC. Their definition is provided by the sending component.

Table 48: External Events received by PlayandRecognize RC

Event	Source	Payload	Sequencing	Description
playStarted	PromptQueue	bargein (O), bargeintype (O), inputtimeout (O)	pq:play notification
playDone	PromptQueue	markname (O), marktime (O)	pq:play response
bargeinChange	PromptQueue	bargein (M)
bargeintypeChange	PromptQueue	bargeintype (M)
prepared	Recognizer		prepare positive response
notPrepared	Recognizer		prepare negative response
inputStarted	Recognizer
recoResult	Recognizer	results (M), listener (O)

6.10.2.2.4 State Chart Representation

The main states for the PlayandRecognize RC are shown in Figure 13.

Figure 13: PlayandRecognize RC States

6.10.2.2.5 SCXML Representation

<?xml version="1.0" encoding="UTF-8"?>

<scxml initialstate="Created">
  <datamodel>
    <data id="controller"/>
    <data id="bargein"/>
    <data id="bargeintype"/>
    <data id="inputmodes"/>
    <data id="inputtimeout"/>
    <data id="dtmfProps"/>
    <data id="asrProps"/>
    <data id="maxnbest"/>
    <data id="recoActive"/>
    <data id="markname"/>
    <data id="marktime"/>
    <data id="recoResult"/>
    <data id="recoListener"/>
    <data id="activeGrammars"/>
  </datamodel>

  <state id="Created">
    <initial id="Idle"/>

    <state id="Idle">
      <onentry>
        <assign location="$controller" val="null"/>
        <assign location="$bargein" expr="true"/>
        <assign location="$bargeintype" val="speech"/>
        <assign location="$inputmodes" val="voice"/>
        <assign location="$inputtimeout" val="0s"/>
        <assign location="$dtmfProps" val="null"/>
        <assign location="$asrProps" val="null"/>
        <assign location="$maxbest" val="1"/>
        <assign location="$recoActive" val="false"/>
        <assign location="$markname" val="null"/>
        <assign location="$marktime" val="0"/>
        <assign location="$recoResult" val="null"/>
        <assign location="$recoListener" val="null"/>
        <assign location="$activeGrammars" val="false"/>
      </onentry>

      <transition event="execute" target="PrepareRecognitionResources">
        <assign name="/datamodel/data/[@name='controller']" expr="_eventData/controller"/>
        <assign name="/datamodel/data/[@name='inputmodes']" expr="_eventData/modes"/>
        <assign name="/datamodel/data/[@name='inputtimeout']" expr="_eventData/timeout"/>
        <assign name="/datamodel/data/[@name='dtmfProps']" expr="_eventData/dtmfProps"/>
        <assign name="/datamodel/data/[@name='asrProps']" expr="_eventData/asrProps"/>
        <assign name="/datamodel/data/[@name='maxnbest']" expr="_eventData/maxnbest"/>
      </transition>

    </state>
    <!-- end Idle -->

    <state id="PrepareRecognitionResources">

      <transition target="StartPlaying" cond="$activeGrammars eq 'true'"/>

      <transition target="Exit" cond="$activeGrammars eq 'false'">
        <send target="controller" event="error.semantic"/>
      </transition>

    </state>
    <!-- end PrepareRecognitionResources -->

    <state id="StartPlaying">
      <onentry>
        <send target="PromptQueue" event="pq:play"/>
      </onentry>

      <transition event="pq:playStarted" cond="$bargein eq 'true'" target="PlayingWithBargein">
        <assign location="$bargein" expr="_eventdata/bargein"/>
      </transition>

      <transition event="pq:playStarted" cond="$bargein eq 'false'" target="PlayingWithoutBargein">
        <assign location="$bargein" expr="_eventdata/bargein"/>
      </transition>

      <transition event="pq:playDone" target="StartRecognizingWithTimer"/>
    </state>
    <!-- end StartPlaying -->

    <state id="PlayingWithoutBargein">
      <onentry>
        <if cond="$recoActive eq 'true'">
          <if cond="in('dtmf',$inputmodes) ">
            <send target="DTMFRecognizer" event="rec:suspend"/>
          </if>
          <if cond="in('voice',$inputmodes) ">
            <send target="DTMFRecognizer" event="rec:suspend"/>
          </if>
        </if>

      </onentry>

      <transition event="bargeintypeChange" cond="_eventdata/value neq 'unbargeable'" target="PlayWithBargein">
        <assign location="$bargein" val="true"/>
        <assign location="$bargeintype" expr="_eventdata/value"/>
      </transition>

      <transition event="pq:playDone" target="StartRecognizingWithTimer">
        <assign location="$markname" expr="_eventdata/markname"/>
        <assign location="$marktime" expr="_eventdata/marktime"/>
      </transition>

    </state>
    <!-- end PlayingWithoutBargein -->

    <state id="PlayingWithBargein">
      <datamodel>
        <data id="negorpos"/>
      </datamodel>
      <onentry>
        <if cond="in('dtmf',$inputmodes) ">
          <send target="DTMFRecognizer" event="rec:listen"/>
        </if>
        <if cond="in('voice',$inputmodes)">
          <send target="DTMFRecognizer" event="rec:listen"/>
        </if>
        <assign location="$recoActive" val="true"/>
      </onentry>

      <transition event="bargeintypeChange" cond="_eventdata/value neq 'unbargeable'">
        <assign location="$bargeintype" expr="_eventdata/value"/>
      </transition>

      <transition event="rec:recoResult">
        <assign location="$negorpos" expr="processRecoResult()"/>
        <send target="parent" event="negorpos"/>
      </transition>

      <transition event="negativeRecoResult">
        <send target="rec_source" event="listen"/>
      </transition>

      <transition event="pq:playDone" target="StartRecognizingWithTimer">
        <assign location="$markname" expr="_eventdata/markname"/>
        <assign location="$marktime" expr="_eventdata/marktime"/>
      </transition>

      <transition event="positiveRecoResult">
        <send target="PromptQueue" event="pq:halt"/>
      </transition>

      <transition event="rec:inputStarted" cond="$bargeintype eq 'speech'">
        <send target="PromptQueue" event="pq:halt"/>
      </transition>

    </state>
    <!-- end PlayingWithBargein -->

    <state id="StartRecognizingWithTimer">
      <onentry>
        <send target="Timer" event="start" namelist="$inputtimeout"/>
        <if cond="$recoActive eq 'false'">
          <if cond="in('dtmf',$inputmodes) ">
            <send target="DTMFRecognizer" event="rec:listen"/>
          </if>
          <if cond="in('voice',$inputmodes)">
            <send target="DTMFRecognizer" event="rec:listen"/>
          </if>
          <assign location="$recoActive" val="true"/>
        </if>
      </onentry>
      <transition event="execute" target="Executing">
        <send target="PlayAndRecognize" event="execute" namlist="self, inputmodes"/>
      </transition>
    </state>
    <!-- end StartRecognizingWithTimer-->

    <state id="WaitingForInput">
      <datamodel>
        <data id="negorpos"/>
      </datamodel>

      <transition event="rec:recoResult">
        <assign location="$negorpos" expr="processResults()"/>
        <send target="parent" event="negorpos"/>
      </transition>

      <transition event="negativeRecoResult">
        <send target="rec_source" event="listen"/>
      </transition>

      <transition event="timerExpired">
        <send target="Recognizer" event="rec:stop"/>
        <send target="controller" event="noinput"/>
      </transition>

      <transition event="rec:inputStarted" cond="$bargeintype eq 'speech'" target="WaitingForSpeechResult">
        <send target="Timer" event="cancel"/>
      </transition>

    </state>
    <!-- end WaitingForInput-->

    <state id="WaitingForSpeechResult">
      <datamodel>
        <data id="negorpos"/>
      </datamodel>

      <!--TBD: the original diagram seems put the event at the wrong place-->
      <transition event="rec:recoResult" target="UpdateResults">
        <assign location="$negorpos" expr="processResults()"/>
        <send target="parent" event="negorpos"/>
      </transition>
    </state>
    <!-- end WaitingForSpeechResult-->

    <state id="UpdateResults">
      <onentry>
        <send target="datamodel" namelist="application, lastresult$, recoResults"/>
        <if cond="$negorpos neq 'null'">
          <send target="recoListener" event="recoResult" namelist="recoResults"/>
          <else/>
          <send target="controller" event="nomatch"/>
        </if>
      </onentry>

      <transition target="Exit"/>
    </state>
    <!-- end UpdateResults-->
  </state>
  <!-- end Created -->

</scxml>

6.11.1 Usage of Platform Grammars

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.

6.11.2 Platform Requirements

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

6.11.3 Syntax and Semantics

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.

6.11.4 Examples

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>            
       

6.12.1 Overview

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.

6.12.2 Semantics

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.

6.12.3 Syntax

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.

    <var name="phone" expr="'6305551212'"/>

    <var name="y" expr="document.z+1"/>

    <var name="foo" scope="application" expr="dialog.bar * 2"/>

    <var name="itinerary">
      <root xmlns="">
        <flight>SW123</flight>
        <origin>JFK</origin>
        <depart>2009-01-01T14:32:00</depart>
        <destination>SFO</destination>
        <arrive>2009-01-01T18:14:00</arrive>
      </root>
    </var>
   

    <value expr="application.duration + dialog.duration"/>

    <value expr="foo * bar"/>

    <value expr="foo + bar + application.baz" scope="document"/>
   

    <assign name="phone" expr="'6305551212'"/>

    <assign name="y" expr="document.z+1"/>

    <assign name="application.foo" expr="dialog.bar * 2"/>

    <assign name="itinerary">
      <root xmlns="">
        <flight>SW123</flight>
        <origin>JFK</origin>
        <depart>2009-01-01T14:32:00</depart>
        <destination>SFO</destination>
        <arrive>2009-01-01T18:14:00</arrive>
      </root>
    </var>
   

    <?xml version="1.0" encoding="UTF-8"?>
    <quote xmlns="http://www.example.org">
      <ticker>F</ticker>
      <name>Ford Motor Company</name>
      <change>0.10</change>
      <last>3.00</last>
    </quote>
   

    <?xml version="1.0" encoding="UTF-8"?>
    <vxml xmlns="http://www.w3.org/2001/vxml" 
      version="2.1"
      xmlns:ex="http://www.example.org"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
      xsi:schemaLocation="http://www.w3.org/2001/vxml 
      http://www.w3.org/TR/2007/REC-voicexml21-20070619/vxml.xsd">

      <var name="quote"/>
      <var name="tickers">
        <tickers xmlns="">
          <ford>f</ford>
          <!-- etc., the dialog below hardcodes ford -->
        </tickers>
      </var>

      <form id="get_quote">
        <block>
          <data name="quote" scope="document"
            srcexpr="'http://www.example.org/getquote?ticker=' + document('tickers')/ford"/>
          <goto next="#play_quote"/>         
        </block>
      </form>

      <form id="play_quote">
        <block>
          <var name="name" expr="document('quote')/ex:name"/>
          <var name="change" expr="document('quote')/ex:change"/>
          <var name="last" expr="document('quote')/ex:last"/>
          <var name="dollars" expr="fn:floor(last)"/>
          <var name="cents" expr="fn:substring(last,fn:string-length(last)-1)"/>

          <!--play the company name -->
          <audio expr="document('tickers')/ford + '.wav'"><value expr="name"/></audio>
          <!-- play 'unchanged, 'up', or 'down' based on zero, positive, or negative change -->
          <if cond="change = 0">
            <audio src="unchanged_at.wav"/>
          <else/>
            <if cond="change &gt; 0">
              <audio src="up.wav"/>
            <else/> <!-- negative -->
              <audio src="down.wav"/>
            </if>
            <audio src="by.wav"/>
            <!-- play change in value as positive number -->
            <audio expr="fn:abs(change) + '.wav'"><value expr="fn:abs(change)"/></audio>
            <audio src="to.wav"/>
          </if>
          <!-- play the current price per share -->
          <audio expr="dollars + '.wav'"><value expr="dollars"/></audio>
          <if cond="cents &gt; 0">
            <audio src="point.wav"/>
            <audio expr="cents + '.wav'"><value expr="cents"/></audio>
          </if>
        </block>
      </form>
    </vxml>
   

  <clear namelist="city state zip"/>

  <clear namelist="application.foo dialog.bar baz"/>

  <clear namelist="alpha beta application.gamma" scope="document"/>

  <clear/>

  <clear scope="dialog"/>
   

6.12.4 Backward compatibility with VoiceXML 2.1

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.

6.12.5 Implicit functions using XPath

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.

6.13.1 Receiving external messages within a voice application

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:

<vxml version="2.1"
  xmlns="http://www.w3.org/2001/vxml">
  <property name="externalevents.enable" value="true"/>
  <var name="myMessages" expr="new Array()"/>

  <catch event="externalmessage">
    <var name="lm" expr="application.lastmessage$"/>
    <if cond="lm.contenttype == 'text/xml' || lm.contenttype == 'application/xml'">
      <log>received XML with root document element
        <value expr="lm.content.documentElement.nodeName"/>
      </log>
    <elseif cond="typeof lm.content == 'string'"/>
      <log>received <value expr="lm.content"/></log>
    <else/>
      <log>received unknown external message type
        <value expr="typeof lm.content"/>
      </log>
    </if>
    <script>
      myMessages.push({'content' : lm.content, 'ctype' : lm.contenttype});
    </script>
  </catch>

  <form>
  <field name="num" type="digits">
    <prompt>pick a number any number</prompt>
    <catch event="noinput nomatch">
      sorry. didn't get that.
      <reprompt/>      
    </catch>
    <filled>
      you said <value expr="num"/>
      <clear/>
    </filled>
  </field>
  </form>
</vxml>

<vxml version="2.1"
  xmlns="http://www.w3.org/2001/vxml">

  <property name="externalevents.queue" value="true"/>
  <form>
    <catch event="error.badfetch">
      <log>timed out waiting for external message</log>
    </catch>
  
    <block>
      Hold on ...
      <receive maxtime="15s" 
        fetchaudio="http://www.example.com/audio/fetching.wav"/>
      <log>got <value expr="application.lastmessage$.content"/></log>
    </block>  
  </form>
</vxml>

6.13.2 Sending messages from a voice application

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>

6.14.1 Syntax

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.

6.14.2 Semantics

The session attribute is an optional attribute on vxml tag. It is a URI reference just like the application attribute is (same URI resolution). If a VXML session has not yet encountered a document with a session root then upon encountering the first vxml document that has a session root, the session root document is loaded and parsed just like how a normal vxml document would load and parse an application root document. If a VXML session has already loaded a different session root then the behavior when a future session attributes is encountered is controlled by the requiresession attribute. If the requiresession attribute is true then encountering a session root attribute with a different URL then the already loaded session root is an error and an error.badfetch is generated. If the requiresession attribute is false then the new session attribute is ignored and the old one is used. The requiresession attribute defaults to false if not present. The behavior of the session root is completely the same as the behavior of the application root, except that while executing in the session root the vxml browser is allowed to write to the javascript session scope, and variables declared as child of the vxml tag thus become session scope variables. In particular, in VXML 2.0 section 5.1.2 when talking about the variable scopes the text for application in table 40 is also appropriate for session (new text "These are declared with <var> and <script> elements that are children of the session root document's <vxml> element. They are initialized when the session root document is loaded. They exist while the session document is loaded, and are visible to the session root document, the application root document, and any other loaded application leaf document.").

This session document then is loaded and active in the hierarchy of documents that follows the javascript scope chaining (that is a document is below an application root is below a session root). This means that if a variable is declared in the session root and then in some local form in the leaf document the variable would be shadowed (just like how the shadowing from the application root).

This also implies that the catch selection algorithm as described in VXML 2.0 section 5.2.4 would have to change to include the session root document as a potential source of catch handlers (new text "Form an ordered list of catches consisting of all catches in the current scope and all enclosing scopes (form item, form, document, application root document, session root document, interpreter context), ordered first by scope (starting with the current scope), and then within each scope by document order."). Then all catch handling would remain the same, in particular the as-if-by copy semantics are retained so if an event from a leaf document was handled by a catch handler from the session root the catch handler wouldn't execute within the context of the session root document but would instead execute as if by copy into the local leaf document context.

This also implies that property lookup from section 6.3 of VXML 2.0 would have to change to say that property value lookup can also go to the session root, if a more local value for the property isn't found (new text "Properties may be defined for the whole session, for the whole application, for the whole document at the <vxml> level, for a particular dialog at the <form> or <menu> level, or for a particular form item.). This doesn't change the usual way properties work where a property at a lower level override one at a higher level.

This also implies that the behavior for link's that are document-level link of session roots are active which would be a change to section 2.5 of VXML 2.0 (new text "If an application root document has a document-level link, its grammars are active no matter what document of the application is being executed. If an session root document has a document-level link, its grammars are active no matter what document of the session is being executed. If execution is in a modal form item, then link grammars at the form, document, application or session level are not active.").

Similar to for links, the scope of grammars from section 3.1.3 of VXML 2.0 would be changed to specify what happens when a grammar from a session root has document scope (new text "Form grammars are by default given dialog scope, so that they are active only when the user is in the form. If they are given scope document, they are active whenever the user is in the document. If they are given scope document and the document is the application root document, then they are also active whenever the user is in another loaded document in the same application. If they are given scope document and the document is the session root document, then they are also active throughout the session.". Note that this active throughout the session can still be trumped by modal listen states (just like the application root can). Section 3.1.4 of VXML 2.0 also changes the activation of grammars bulleted list to include the session root (new text: "grammars contained in links in its application root document or session root document, and grammars for menus and forms in its application root document or session root document which are given document scope.").

6.14.3 Examples

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.

6.15.1 <rtc>

6.15.2 <cancelrtc>

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

6.15.3 Semantics

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.

6.15.4 Examples

T.B.D.

6.16.1 SIV Core Functions

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.

6.16.2 Syntax

[Schema definition TBD]

6.16.3 Semantics

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

6.16.4 Events

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

6.16.5 Examples

[Examples TBD]

6.17.1 Syntax

TBD.

6.17.2 Semantics

TBD

6.17.3 Examples

TBD

6.18.1 Syntax

[See XXX for schema definitions].

6.18.2 Semantics

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

<?xml version="1.0" encoding="UTF-8"?>
<scxml initialstate="Created">
  <datamodel>
    <data id="controller"/>
    <data id="namelist"/>
    <data id="bargein"/>
    <data id="activeGrammars"/>
  </datamodel>
 
  <state id="Created">
    <initial id="Idle"/>
 
    <state id="Idle">
      <onentry>
        <assign location="$controller" val="null"/>
        <assign location="$bargein" val="false"/>
        <assign location="$activeGrammars" val="false"/>
      </onentry>
 
      <transition event="initialize" target="Initializing">
        <assign name="$controller" expr="_eventData/controller"/>
        <send target="controller" event="initializing.done" />   
      </transition>
    </state>
    <!-- end Idle -->
 
    <state id="Initializing">
      <transition event="initializing.done" target="Ready">
        <send target="controller" event="initialized"/>
      </transition>
    </state>
    <!-- end Initializing -->
 
    <state id="Ready">
      <transition event="execute" target="Executing">
        <send target="Play" event="execute"/>   
      </transition>
    </state>
    <!-- end Ready -->
 
    <state id="Executing">
      <transition event="playDone" target="Disconnecting">    // Currently no such event as "Play.done"
        <send target="controller" event="disconnectUser" />
      </transition>
    </state>
    <!-- end Executing -->
 
    <state id="Disconnecting">
      <transition event="userDisconnected" target="Ready">                        
        <!-- A call to disconnect the interpreter context from the user -->        
        <send target="parent" event="connection.disconnect.hangup" />   
        <send target="controller" event="executed" />   
      </transition>
    </state>
    <!-- end Disconnecting -->
</scxml>

6.18.3 Example

<vxml version="2.1"  xmlns="http://www.w3.org/2001/vxml">
  <catch event="connection.disconnect.hangup">
    <goto next="finalprocessing.jsp" />
  </catch>
  <form>
  <field name="phoneNum" type="digits">
    <prompt>Due to some technical difficulties, we cannot process your request now. Please enter your phone number so that we can get back to you later.</prompt>
    <catch event="noinput">
      Disconnecting.
      <disconnect/>
    </catch>
    <filled>
      <disconnect namelist="phoneNum"/>
    </filled>
  </field>
  </form>
</vxml>

6.19.1 Semantics

The Play RC coordinates media output with the PromptQueue Resource (5.2 Prompt Queue Resource).

6.19.1.4 State Chart Representation

Figure 14: Play RC States

<?xml version="1.0" encoding="UTF-8"?>
 
<scxml initialstate="Created">
  <datamodel>
    <data id="controller"/>
    <data id="bargein"/>
  </datamodel>
  
  <state id="Created">
    <initial id="Idle"/>
 
    <state id="Idle">
      <onentry>
        <assign location="$controller" val="null"/>
        <assign location="$bargein" val="false"/>
      </onentry>
 
      <transition event="execute" target="Playing">
        <assign name="$controller" expr="_eventData/controller"/>
        <send target="PromptQueue" event="play" namelist="/datamodel/data[@name='bargein']"/>    
      </transition>
    </state> <!-- end Idle -->
 
    <state id="Playing">
      <transition event="prompt.done" target="Idle">
        <send target="controller" event="playDone"/>
      </transition>
    </state> <!-- end StartPlaying -->
    
  </state> <!-- end Created -->
 
</scxml>

6.20.1 Syntax

[See XXX for schema definitions].

6.20.2 Semantics

The semantics of the record module are defined using the following resource controllers: RecordInputItem (6.20.2.1 RecordInputItem RC), PlayandRecognize (6.10.2.2 PlayandRecognize RC), Record (6.20.2.2 Record RC).

6.20.2.1 RecordInputItem RC

The Record Input Item Resource Controller is the primary RC for the record element.

6.20.2.1.1 Definition

The record input item RC is defined in terms of a data model and a state model.

The data model is composed of the following parameters:

• controller: the RC controlling this record input item RC
• children: array of children's (primary) RC
• includePrompts: boolean indicating whether prompts are to be collected and queued. Default: true.
• promptCounter: prompt counter. Default: 1
• eventCounterStructure: A hashtable like structure that stores the current event count for any given complete named event. If an event isn't present then it gets a count of 1.
• recordResult: this stores a reference to the recorded file (it is platform specific if this is the data, a URI to the data, a filename, or what not).
• expr: expression for the initial value of the form item
• cond: condition if we should be selected
• modal: condition if we should have non-local grammars active
• dtmfterm: Boolean if we should terminate on dtmf or not
• beep: Boolean if we should play a beep or not
• finalsilence: number indicating the length of time we should wait for record to be done

6.20.2.1.2 Defined Events

The RecordInputItem RC is defined to receive the following events:

[Table contents TBD]

Table 87: Events received by RecordInputItem RC

Event	Source	Payload	Description

and the events it sends:

Table 88: Events sent by RecordInputItem RC

Event	Target	Payload	Description

6.20.2.1.3 External Events

Table 89 shows the events sent and received by the record input item RC to resources and other RCs which define the events.

[Table contents TBD]

Table 89: RecordInputItem RC External Events

Event	Source	Target	Description

6.20.2.1.4 State Chart Representation

Figure 15: RecordInputItem RC States

6.20.2.1.5 SCXML Representation

6.20.2.2 Record RC

The Record RC coordinates media with the Record resource and a form item. It is expected that other functionality that may be related or simultaneous such as prompt playing or recognition will be handled by the form item's rc. The record RC only handles the recording.

6.20.2.2.1 Definition

The record RC is defined in terms of a data model and a state model.

The data model is composed of the following parameters:

• controller: the RC controlling this record RC
• recordParams: the collection of parameters needed for recording. This will eventually be broken up but currently the only ones that effect the RC are timeout and maxtime. Others such as final silence may be passed directly to the Recording resource.

6.20.2.2.2 Defined Events

The Record RC is defined to receive the following events:

Table 90: Events received by Record RC

Event	Source	Payload	Sequencing	Description
execute	any	controller (M), recordParams (O)

and the events it sends:

Table 91: Events sent by Record RC

Event	Target	Payload	Sequencing	Description
recordDone	controller	RecordResults (M)	One-of: recordDone, noinput
noinput	controller		One-of: recordDone, noinput

6.20.2.2.3 External Events

Table 92 shows the events sent by the record RC to various resources.

Table 92: External Events sent by Record RC

Event	Target	Payload	Sequencing	Description
start	Timer	timeout (M)
cancel	Timer
start	Record Resource	recoParams (M)
stop	Record Resource	maxtime (M)		This causes the recording to stop and return the recording information, setting a Boolean about if the recording was stopped because of maxtime
kill	Record Resource			This immediately stops the record resource, throwing away any recording
assign	Datamodel Resource	name (M), value (M)

Table 93 shows the events received by the record RC. Their definition is provided by the sending component.

Table 93: External Events received by Record RC

Event	Source	Payload	Sequencing	Description
TimerExpired	Timer
Started	Record Resource			This event means a recording has begun. This may be automatic as soon as start was sent to the resource, or there may be an optimization where this doesn't get sent until after the record resource detects speech.

6.20.2.2.4 State Chart Representation

Figure 16: Record RC States

6.20.2.2.5 SCXML Representation

6.21.1 Syntax

[See XXX for schema definitions].

6.21.2 Semantics

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.

6.21.3 Events

[Events raised during initialization and execution TBD.]

6.21.4 Examples

[TBD: put all examples here.]

6.22.1 Syntax

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.

[See XXX for schema definitions].

6.22.2 Semantics

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.

6.22.3 Events

6.22.4 Examples

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>

7.1.1 Conformance

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:

• Vxml Root Module
• Script Module
• 6.9 Form Module
• 6.10 Field Module
• 6.4 Prompt Module: this includes implementation of 6.5 Builtin SSML Module and 6.8 Foreach Module.
• 6.1 Grammar Module: this includes implementation of 6.2 Inline SRGS Grammar Module and 6.3 External Grammar Module.
• 6.12 Data Access and Manipulation Module
• Executable Content
• Link
• Record
• Object
• Event Throwing/Handling
• Transfers

7.1.2 Vxml Root Module Requirements

Eliminate the need to specify Session Root and Platform Root.

7.1.3 Form Module Requirements

Eliminate Capture phase of DOM Level 3 eventing to support Legacy Profile.

7.1.4 Field Module Requirements

Eliminate Capture phase of DOM Level 3 eventing to support Legacy Profile.

7.1.5 Prompt Module Requirements

Eliminate Capture phase of DOM Level 3 eventing to support Legacy Profile.

7.1.6 Grammar Module Requirements

Eliminate Capture phase of DOM Level 3 eventing to support Legacy Profile.

7.1.7 Data Access and Manipulation Module Requirements

Eliminate Capture phase of DOM Level 3 eventing to support Legacy Profile.

7.2.1 Introduction

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.

7.2.2 What the Basic Profile includes

The following enumerates the modules included in the Basic Profile.

7.2.3 Returned results

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

7.2.4 What the Basic Profile does not include

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>

7.2.5 Examples

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]

8.1.1 Fetching

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.

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 4.5.2.2 Application Root 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:

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.

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

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

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

8.2.1 Speech Recognition Properties

The following generic speech recognition properties are defined.

8.2.2 DTMF Recognition Properties

The following generic DTMF recognition properties are defined.

8.2.3 Prompt and Collect Properties

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

8.2.4 Media Properties

The following properties are defined to apply to output media.

8.2.5 Fetch Properties

The following properties pertain to the fetching of new documents and resources.

Note that maxage and maxstale properties may have no default value - see 8.1.2 Caching.

8.2.6 Miscellaneous Properties

The following miscellaneous properties are defined.

8.3.1 DTMF Grammars

DTMF grammars use timeout, interdigittimeout, termtimeout and termchar as described in 8.2.2 DTMF Recognition Properties to tailor the user experience. The effects of these are shown in the following timing diagrams.

8.3.2 Speech Grammars

Speech grammars use timeout, completetimeout, and incompletetimeout as described in 8.2.3 Prompt and Collect Properties and 8.2.1 Speech Recognition Properties to tailor the user experience. The effects of these are shown in the following timing diagrams.

8.4.1 Integers

Integers are specified in decimal notation only. Integers may be preceded by a "-" or "+" to indicate the sign.

An integer consists of one or more digits "0" to "9".

8.4.2 Real Numbers

Real numbers are specified in decimal notation only. Real numbers may be preceded by a "-" or "+" to indicate the sign.

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.

8.4.3 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".

9.2.1 SCXML for Dialog Management

Example application scenario:

• This is an airline travel itinerary modification application
• First order of business is to retrieve an itinerary to be modified
• Itinerary may be identified using either a record locator or traveler's lastname and other information

Below are two flavors of this application using SCXML as the form-level controller, a system-driven and a user-driven approach. These use similar set of fields in the form but different dialog management styles. In the simpler example here, the VUI might appear similar though there is a system vs. user driven flavor.

<v3:scxmlform>

  <scxml:scxml initial="choice">

    <scxml:state id="choice">
      <scxml:invoke type="vxml3field" src="#choicefield"/>
      <scxml:transition event="filled.choice" cond="choicefield"
                    target="locator"/>
      <scxml:transition event="filled.choice" cond="!choicefield"
                    target="lastname"/>
    </scxml:state>

    <scxml:state id="locator">
      <scxml:invoke type="vxml3field" src="#locatorfield"/>
      <!-- Retrieve record, transition to app menu -->
    </scxml:state>

    <scxml:state id="lastname">
      <scxml:invoke type="vxml3field" src="#lastnamefield"/>
      <!-- Collect other information needed to retrieve record,
           then retrieve record and go to app menu -->
    </scxml:state>

    <!-- Remaining dialog control flow logic omitted -->

  </scxml:scxml>

  <v3:field name="choicefield">
    <v3:grammar src="boolean.grxml" type="application/srgs+xml"/>
    <v3:prompt>
      Welcome. Do you have the record locator for your itinerary?
    <v3:prompt>
    <v3:filled>
      <v3:throw event="filled.choice"/>
    </v3:filled>
  </v3:field>

  <v3:field name="locatorfield">
    <v3:grammar src="locator.grxml" type="application/srgs+xml"/>
    <v3:prompt>
      What is the record locator for the itinerary?
    <v3:prompt>
    <v3:filled>
      <v3:throw event="filled.locator"/>
    </v3:filled>
  </v3:field>

  <v3:field name="lastnamefield">
    <v3:grammar src="lastname.grxml" type="application/srgs+xml"/>
    <v3:prompt>
      Please say or spell your last name.
    <v3:prompt>
    <v3:filled>
      <v3:throw event="filled.lastname"/>
    </v3:filled>
  </v3:field>

  <!-- Other form items, such as the subsequent application menu omitted
-->

</v3:scxmlform>

<v3:scxmlform>

  <scxml:scxml initial="choice">

    <scxml:state id="choice">
      <scxml:invoke type="vxml3field" src="#choicefield"/>
      <scxml:transition event="filled.choice" cond="choicefield == 'locator'"
                    target="locator"/>
      <scxml:transition event="filled.choice" cond="choicefield == 'lastname'"
                    target="lastname"/>
    </scxml:state>

    <scxml:state id="locator">
      <scxml:invoke type="vxml3field" src="#locatorfield"/>
      <!-- Retrieve record, transition to app menu -->
    </scxml:state>

    <scxml:state id="lastname">
      <scxml:invoke type="vxml3field" src="#lastnamefield"/>
      <!-- Collect other information needed to retrieve record,
           then retrieve record and go to app menu -->
    </scxml:state>

    <!-- Remaining dialog control flow logic omitted -->

  </scxml:scxml>

  <v3:field name="choicefield">
    <v3:grammar src="choice.grxml" type="application/srgs+xml"/>
    <v3:prompt>
      Welcome. How would you like to look up your itinerary?
    <v3:prompt>
    <v3:filled>
      <v3:throw event="filled.choice"/>
    </v3:filled>
  </v3:field>

  <v3:field name="locatorfield">
    <v3:grammar src="locator.grxml" type="application/srgs+xml"/>
    <v3:prompt>
      What is the record locator for the itinerary?
    <v3:prompt>
    <v3:filled>
      <v3:throw event="filled.locator"/>
    </v3:filled>
  </v3:field>

  <v3:field name="lastnamefield">
    <v3:grammar src="lastname.grxml" type="application/srgs+xml"/>
    <v3:prompt>
      Please say or spell your last name.
    <v3:prompt>
    <v3:filled>
      <v3:throw event="filled.lastname"/>
    </v3:filled>
  </v3:field>

  <!-- Other form items, such as the subsequent application menu omitted
-->

</v3:scxmlform>

9.2.2 Graceful Degradation

One possibility with this approach is that the absence of an <scxml:scxml> child element in a <v3:scxmlform> could revert behavior to be identical to a <v2:form> element where the V2 Form Interpretation Algorithm would be in charge. In the presence of a <scxml:scxml> child, the FIA would be suppressed and the more expressive SCXML controller used, which would allow application developers to design the form VUI in a very flexible manner. In other words, the following <v3:scxmlform> below:

<v3:scxmlform>

  <!-- No SCXML child -->

  <!-- Various form items etc. -->

</v3:scxmlform>

behaves as would:

<v2:form>

  <!-- Various form items etc. -->

</v2:form>

9.2.3 SCXML as Basis for Recursive MVC

The above example illustrated a form-level SCXML controller. SCXML could perhaps also be used as a document level controller, where it would be managing the interaction across v3:forms, rather than v3:fields. To illustrate:

<v3:vxml>

  <scxml:scxml ...>
    <!-- document level controller managing interaction
         across form1, form2 and form3 -->
  </scxml:scxml>

  <v3:form id="form1">
    <!-- form1 content, might also have a form level SCXML controller -->
  </v3:form>

  <v3:form id="form2">
    <!-- form2 content, might also have a form level SCXML controller -->
  </v3:form>

  <v3:form id="form3">
    <!-- form3 content, might also have a form level SCXML controller -->
  </v3:form>

</v3:vxml>