[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. Note that the VXML 2.0 style events are supported through a new DOM event named 'vxmlevent', and if this vxmlevent is uncanceled then the default action is to run the VXML 2.0 event handling.

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.

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

Editorial note

Open Issue: Should ClearContextRequest be handled automatically? Should Done be sent automatically when the document is finished? Where do these response events get sent?

D VoiceXML 3.0 XML Schema for schema definitions].

[SRGS]), minus the XML Prolog. Note that both elements and attributes must be in the SRGS namespace (http://www.w3.org/2001/06/grammar).

D VoiceXML 3.0 XML Schema for schema definitions].

D VoiceXML 3.0 XML Schema for schema definitions].

D VoiceXML 3.0 XML Schema 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, in addition to the fetchtimeout, fetchhint, maxage, and maxstale attributes as specified in 8.1.1 Fetching.

Conforming Speech Synthesis Markup Language Processor.

Evaluation consits of the following:

• 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 anything other than a valid URI string, then the expr attribute and its content are removed. 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

Editorial note

Need to specify further error cases Need to clarify unsupported languages and external (e.g. MRCP) SSML processors.

D VoiceXML 3.0 XML Schema for schema definitions].

D VoiceXML 3.0 XML Schema for schema definitions].

6.10.2.1 Field RC), PlayandRecognize (6.10.2.2 PlayandRecognize RC), ...

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

D VoiceXML 3.0 XML Schema for schema definitions].

The <voicemodel> element has the attributes specified in Table 72, in addition to the fetchtimeout, fetchhint, maxage, and maxstale attributes as specified in 8.1.1 Fetching.

D VoiceXML 3.0 XML Schema for schema definitions].

5.2 Prompt Queue Resource).

D VoiceXML 3.0 XML Schema for schema definitions].

6.20.2.1 RecordInputItem RC), PlayandRecognize (6.10.2.2 PlayandRecognize RC), Record (6.20.2.2 Record RC).

D VoiceXML 3.0 XML Schema for schema definitions].

D VoiceXML 3.0 XML Schema for schema definitions].

9.2 Integrating Flow Control Languages into VoiceXML.

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

The schema for the Legacy Profile is given in D.8 Schema for Legacy Profile.

Editorial note

The following content is missing from the Vxml 3.0 specification and needs to be defined: Vxml Root Module Event Handling and throwing (event handlers like <catch>, <noinput>,<nomatch>, etc.) FIA? (although talked about in the Form module, it is not addressed completely) Executable Content <reprompt> <disconnect> <exit> <if> <elseif> <else> <goto> <submit> <log> <return> <script> <throw> All of the VoiceXML 2.0/2.1 properties (Should go in 6.12) <script> Script Module <transfer> <initial> <link> <record> <object> Transitions: <goto>, <submit>, <subdialog> Specify transitions amongst inter-module clearly author controlled transitions within form author controlled transitions outside form automatic transition behavior outside form <filled> Supported media types must be defined.

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:

Table 97: Additional Fetch Attribute

fetchaudio

The URI of the audio clip to play while the fetch is being done. If not specified, the fetchaudio property is used, and if that property is not set, no audio is played during the fetch. The fetching of the audio clip is governed by the audiofetchhint, audiomaxage, audiomaxstale, and fetchtimeout properties in effect at the time of the fetch. The playing of the audio clip is governed by the fetchaudiodelay, and fetchaudiominimum properties in effect at the time of the fetch.

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.

[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.2 Caching.

Table 102: Fetch Properties

Name	Description	Default
audiofetchhint	This tells the platform whether or not it can attempt to optimize dialog interpretation by pre-fetching audio. The value is either safe to say that audio is only fetched when it is needed, never before; or prefetch to permit, but not require the platform to pre-fetch the audio.	prefetch
audiofetchtimeout	The timeout for audio fetches. The value is a Time Designation (see 8.4 Value Designations).	platform-specific
audiomaxage	Tells the platform the maximum acceptable age, in seconds, of cached audio resources.	platform-specific
audiomaxstale	Tells the platform the maximum acceptable staleness, in seconds, of expired cached audio resources.	platform-specific
documentfetchhint	Tells the platform whether or not documents may be pre-fetched. The value is either safe (the default), or prefetch.	safe
documentfetchtimeout	The timeout for document fetches. The value is a Time Designation (see 8.4 Value Designations).	platform-specific
documentmaxage	Tells the platform the maximum acceptable age, in seconds, of cached documents.	platform-specific
documentmaxstale	Tells the platform the maximum acceptable staleness, in seconds, of expired cached documents.	platform-specific
grammarfetchhint	Tells the platform whether or not grammars may be pre-fetched. The value is either prefetch (the default), or safe.	prefetch
grammarfetchtimeout	The timeout for grammar fetches. The value is a Time Designation (see 8.4 Value Designations).	platform-specific
grammarmaxage	Tells the platform the maximum acceptable age, in seconds, of cached grammars.	platform-specific
grammarmaxstale	Tells the platform the maximum acceptable staleness, in seconds, of expired cached grammars.	platform-specific.
mediafetchhint	Tells the platform whether or not media files may be pre-fetched. The value is either prefetch (the default), or safe.	prefetch
mediafetchtimeout	The timeout for media fetches. The value is a Time Designation (see 8.4 Value Designations).	platform-specific
mediamaxage	Tells the platform the maximum acceptable age, in seconds, of cached media.	platform-specific
mediamaxstale	Tells the platform the maximum acceptable staleness, in seconds, of expired cached media.	platform-specific.
objectfetchhint	Tells the platform whether the URI contents for <object> may be pre-fetched or not. The values are prefetch, or safe.	prefetch
objectfetchtimeout	The timeout for objectfetches. The value is a Time Designation (see 8.4 Value Designations).	platform-specific
objectmaxage	Tells the platform the maximum acceptable age, in seconds, of cached objects.	platform-specific
objectmaxstale	Tells the platform the maximum acceptable staleness, in seconds, of expired cached objects.	platform-specific
scriptfetchhint	Tells whether scripts may be pre-fetched or not. The values are prefetch (the default), or safe.	prefetch
scriptfetchtimeout	The timeout for script fetches. The value is a Time Designation (see 8.4 Value Designations).	platform-specific
scriptmaxage	Tells the platform the maximum acceptable age, in seconds, of cached scripts.	platform-specific
scriptmaxstale	Tells the platform the maximum acceptable staleness, in seconds, of expired cached scripts.	platform-specific.
fetchaudio	The URI of the audio to play while waiting for a document to be fetched. The default is not to play any audio during fetch delays. There are no fetchaudio properties for audio, grammars, objects, and scripts. The fetching of the audio clip is governed by the audiofetchhint, audiomaxage, audiomaxstale, and fetchtimeout properties in effect at the time of the fetch. The playing of the audio clip is governed by the fetchaudiodelay, and fetchaudiominimum properties in effect at the time of the fetch.	undefined
fetchaudiodelay	The time interval to wait at the start of a fetch delay before playing the fetchaudio source. The value is a Time Designation (see 8.4 Value Designations). The default interval is platform-dependent, e.g. "2s".  The idea is that when a fetch delay is short, it may be better to have a few seconds of silence instead of a bit of fetchaudio that is immediately cut off.	platform-specific
fetchaudiominimum	The minimum time interval to play a fetchaudio source, once started, even if the fetch result arrives in the meantime. The value is a Time Designation (see 8.4 Value Designations). The default is platform-dependent, e.g., "5s".  The idea is that once the user does begin to hear fetchaudio, it should not be stopped too quickly.	platform-specific

8.2.2 DTMF Recognition Properties to tailor the user experience. The effects of these are shown in the following timing diagrams.

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.