Voice Extensible Markup Language (VoiceXML) 3.0 Requirements

W3C Working Draft 8 August 2008

This version:: http://www.w3.org/TR/2008/WD-vxml30reqs-20080808/
Latest version:: http://www.w3.org/TR/vxml30reqs/
Previous version:: This is the first version.
Editors:: Jeff Hoepfinger, SandCherry; Emily Candell, Comverse
Authors:: Jim Barnett, Aspect; Mike Bodell, Microsoft; Dan Burnett, Voxeo; Jerry Carter, Nuance; Scott McGlashan, HP; Ken Rehor, Cisco

The W3C Voice Browser working group aims to develop specifications to enable access to the Web using spoken interaction. This document is part of a set of requirement studies for voice browsers, and provides details of the requirements for marking up spoken dialogs.

Status of this document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This is the 8 August 2008 W3C Working Draft of "Voice Extensible Markup Language (VoiceXML) 3.0 Requirements".

This document describes the requirements for marking up dialogs for spoken interaction required to fulfill the charter given in the Voice Browser Working Group Charter, and indicates how the W3C Voice Browser Working Group has satisfied these requirements via the publication of working drafts and recommendations. This is a First Public Working Draft. The group does not expect this document to become a W3C Recommendation.

This document has been produced as part of the W3C Voice Browser Activity, following the procedures set out for the W3C Process. The authors of this document are members of the Voice Browser Working Group. You are encouraged to subscribe to the public discussion list <www-voice@w3.org> and to mail us your comments. To subscribe, send an email to <www-voice-request@w3.org> with the word subscribe in the subject line (include the word unsubscribe if you want to unsubscribe). A public archive is available online.

This specification is a Working Draft of the Voice Browser working group for review by W3C members and other interested parties. It is a draft document and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress".

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. The group does not expect this document to become a W3C Recommendation. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

0. Introduction

The main goal of this activity is to establish the current status of the Voice Browser Working Group Activities relative to the requirements defined in Previous Requirements Document and define additional requirements to drive future Voice Browser Working Group activities based on Voice Community experience with existing standards

0.1 Scope

The previous requirements definition activity focused on defining three types of requirements on the voice markup language: modality, functional, and format.

The environment and capabilities of the voice browser interpreting the markup language affects these requirements. There may be differences in the modality and functional requirements for desktop versus telephony-based environments (and in the latter case, between fixed, mobile and Internet telephony environments). The capabilities of the voice browser device also impacts on requirements. Requirements affected by the environment or capabilities of the voice browser device will be explicitly marked as such.

0.2 Terminology

Although defining a dialog is highly problematic, some basic definitions must be provided to establish a common basis of understanding and avoid confusion. The following terminology is based upon an event-driven model of dialog interaction.

Voice Markup Language	a language in which voice dialog behavior is specified. The language may include reference to style and scripting elements which can also determine dialog behavior.
Voice Browser	a software device which interprets a voice markup language and generates a dialog with voice output and/or input, and possibly other modalities.
Dialog	a model of interactive behavior underlying the interpretation of the markup language. The model consists of states, variables, events, event handlers, inputs and outputs.
State	the basic interactional unit defined in the markup language; for example, an < input > element in HTML. A state can specify variables, event handlers, outputs and inputs. A state may describe output content to be presented to the user, input which the user can enter, event handlers describing, for example, which variables to bind and which state to transition to when an event occur.
Events	generated when a state is executed by the voice browser; for example, when outputs or inputs in a state are rendered or interpreted. Events are typed and may include information; for example, an input event generated when an utterance is recognized may include the string recognized, an interpretation, confidence score, and so on.
Event Handlers	are specified in the voice markup language and describe how events generated by the voice browser are to be handled. Interpretation of events may bind variables, or map the current state into another state (possibly itself).
Output	content specified in an element of the markup language for presentation to the user. The content is rendered by the voice browser; for example, audio files or text rendered by a TTS. Output can also contain parameters for the output device; for example, volume of audio file playback, language for TTS, etc. Events are generated when, for example, the audio file has been played.
Input	content (and its interpretation) specified in an element of the markup language which can be given as input by a user; for example, a grammar for DTMF and speech input. Events are generated by the voice browser when, for example, the user has spoken an utterance and variables may be bound to information contained in the event. Input can also specify parameters for the input device; for example, timeout parameters, etc.

The dialog requirements for the voice markup language are annotated with the following priorities. If a feature is deferred from the initial specification to a future release, consideration may be given to leaving open a path for future incorporation of the feature.

must have	The first official specification must define the feature.
should have	The first official specification should define the feature if feasible but may defer it until a future release.
nice to have	The first official specification may define the feature if time permits, however, its priority is low.
future revision	It is not intended that the first official specification include the feature.

1. Modality Requirements

1.1 Coordinated, Simultaneous Multimodal Output (nice to have)

1.1.1 The markup language specifies that content is to be simultaneously rendered in multiple modalities (e.g. audio and video) and that output rendering is coordinated. For example, graphical output on a cellular telephone display is coordinated with spoken output.

1.2 Uncoordinated, Simultaneous Multimodal Output (nice to have)

1.2.1 The markup language specifies that content is to be simultaneously rendered in multiple modalities (e.g. audio and video) and that output rendering is uncoordinated. For example, graphical output on a cellular telephone display is uncoordinated with spoken output.

2. Functional Requirements

These requirements are intended to ensure that the markup language is capable of specifying cooperative dialog behavior characteristic of state-of-the-art spoken dialog systems. In general, the voice browser should compensate for its own limitations in knowledge and performance compared with equivalent human agents; for example, compensate for limitations in speech recognition capability by confirming spoken user input when necessary.

2.1 VCR Controls (must have)

2.1.1 VoiceXML 3.0 MUST provide a mechanism giving an application developer a high-level of control of audio and video playback.

2.1.1.1 It MUST be possible to invoke media controls by DTMF or speech input (other input mechanisms may be supported).

2.1.1.2 Media controls MUST not disable normal user input: i.e. input for media control and input for application input MUST be possible simultaneously.

2.1.1.3 Input associated with media controls MUST be treated in the same way as other inputs. Resolution of best match follows standard VoiceXML 2.0 precedence and scoping rules.

2.1.1.4 It MUST be possible for user input to be interpreted as seek controls -- fast forward and rewind -- during media output playback.

2.1.1.5 The seek control MUST allow fast forward and rewind to be specified in time - seconds, milliseconds - relative to the current playback position.

2.1.1.6 The seek control MUST allow fast forward and rewind to be specified relative to <mark> elements in the output.

2.1.1.7 The seek control MUST not affect the selection of alternative content: i.e. the same (alternative) content MUST be used.

2.1.1.8 It MUST be possible for user input to be interpreted as pause/resume during media output playback.

2.1.1.9 It MUST be possible for the different inputs to control pause and resume.

2.2 Media Control (must have)

2.2.1. It MUST be possible to specify a media clip begin value, specified in time, as an offset from the start of the media clip to begin playback.

2.2.2. It MUST be possible to specify a media clip end value, specified in time, as an offset from the start of the media clip to end playback.

2.2.3. It MUST be possible to specify a repeat duration, specified in time, as the amount of time the media file will repeat playback.

2.2.4. It MUST be possible to specify a repeat count, specified as a non-negative integer, as the number of times the media file will repeat playback.

2.2.5. It MUST be possible to specify a gain , specified as a percentage, as the percent to adjust the amplitude playback of the original waveform.

2.2.6. It MUST be possible to specify a speed, specified as a percentage, as the percent to adjust the speed playback of the original waveform.

2.3 Speaker Verification (must have)

2.3.1 The markup language MUST provide the ability to verify a speaker's identity through a dialog containing both acoustic verification and knowledge verification.

The acoustic verification may compare speech samples to an existing model (kept in some, possibly external, repository) of that speaker's voice. A verification result returns a value indicating whether the acoustic and knowledge tests were accepted or rejected. Results for verification and results for recognition may be returned simultaneously.

2.3.1.1 VoiceXML 3.0 MUST support SIV for end-user dialogs

2.3.1.2 SIV features MUST be integrated with VoiceXML 3.0.

SIV features such as enrollment and verification are voice dialogs. SIV must be compatible and complementary with other VoiceXML 3.0 dialog constructs such as speech recognition.

2.3.1.3 VoiceXML 3.0 MUST be able to be used without SIV.

SIV features must be part of VoiceXML 3.0 but may not be needed in all application scenarios or implementations. Not all voice dialogs need SIV.

2.3.1.4 SIV MUST be able to be used without other input modalities.

2.3.1.5 SIV features MUST be able to operate in multi-factor environments.

Some applications require the use of SIV along with other means of authentication: biometric (e.g. fingerprint, hand, retina, DNA) or non-biometric (e.g. caller ID, geolocation, personal knowledge, etc.).

2.3.1.6 SIV-specific events MUST be defined.

SIV processing engines and network protocols (e.g. MRCP) generate events related to their operation and use. These events must be made available in a manner consistent with other VoiceXML events. Event naming structure must allow for vendor-specific and application-specific events.

2.3.1.7 SIV-specific properties MUST be defined.

These properties are provided to configure the operation of the SIV processing engines (analogous to "Generic Speech Recognition Properties" defined in VoiceXML 2.0 Section 6.3.2).

2.3.1.8 The SIV result MUST be available in the result structure used by the host environment (e.g. VoiceXML 3.0, MMI).

Note that this does not require EMMA in all cases, such as non-VoiceXML 3.0 environments. This also does not specify the version of EMMA.

2.3.1.8.1 VoiceXML 3.0 SIV result MUST be representable in EMMA.

VoiceXML 3.0 must specify the format of the result structure and version of EMMA.

2.3.1.9 SIV syntax SHOULD adhere to the W3C guidelines for security handling.

2.3.1.11 SIV features MUST support enrollment.

Enrollment is the process of collecting voice samples from a person and the subsequent generation and storage of voice reference models associated with that person.

2.3.1.12 SIV features MUST support verification.

Verification is the process of comparing an utterance against a single reference model based on a single claimed identity (e.g., user ID, account number). A verification result includes both a score and a decision.

2.3.1.13 SIV features MUST support identification.

Identification is verification with multiple identity claims. An identification result includes both the verification results for all of the individual identity claims, and the identifier of a single reference model that matches the input utterance best.

2.3.1.14 SIV features SHOULD support supervised adaptation.

The application should have control over whether a voice model is updated or modified based on the results of a verification.

2.3.1.15 SIV features MUST support concurrent SIV processing.

An application developer must be able to specify at the individual turn level that one or more of the following types of processing need to be performed concurrently:

2.3.1.15.1 SIV features SHOULD support other concurrent audio processing.

Concurrent processing of other forms of audio processing (e.g., channel detection, gender detection) should also be permitted but remain optional.

2.3.1.16 SIV features MUST be able to accept text from the application for presentation to the user.

Text-prompted SIV applications require prompts to match the expected response. The application is responsible for the content of the dialog but VoiceXML is responsible for the presentation.

2.3.1.16.1 SIV SHOULD be architecturally agnostic

Many different SIV processing technologies exist. The VoiceXML 3.0 SIV architecture should avoid dependencies upon specific engine technologies.

2.4 External Event handling while a dialog is in progress (must have)

2.4.1 It MUST be possible for external entities to inject events into running dialogs. The dialog author MUST be able to control when such events are processed and what actions are taken when they are processed.

2.4.2 Among the possible results of processing such events MUST be pausing, resuming, and terminating the dialog. The VoiceXML 3.0 specification MAY define default handlers for certain such external events.

2.4.3 It MUST be possible for running dialogs to send events into the Multimodal Interaction Framework.

2.5 Pronunciation Lexicon Specification (must have)

2.5.1 The author MUST be able to define lexicons that span an entire VoiceXML application.

2.6 EMMA Specification (must have)

2.6.1. The application author MUST be able to specify the preferred format of the input result within VoiceXML. If not specified, the default format is EMMA.

2.6.2 All available semantic information (ie. content that could have meaning) from the input MUST be accessible to the application author. This result MUST be navigable by the application author.

The exact form of navigation will depend on the format and decisions around the preferred data model made by the working group. If the result is a string, string processing functions are expected to be available. If the result is an XML document, DOM or E4X-like functions are expected to be supported.

2.6.3. VoiceXML 3 (or profiles) MUST describe how the default result format is mapped into the application's data model.

2.6.4 The application author SHOULD be able to specify specific result content not to be logged.

This will allow the author to prevent logging of confidential or sensitive information.

2.7 Synchronous Upload of Recordings (must have)

2.7.1 VoiceXML 3.0 MUST enable synchronous uploads of recordings while the recording is in progress

2.7.1.1 It MUST be possible to specify the upload destination of the recording in the <record> element

2.7.1.2 The upload destination MUST be an HTTP URI

2.7.1.3 The application developer MAY specify HTTP PUT or HTTP POST as the recording upload method

2.7.1.4 This feature MUST be backward compatible with VoiceXML 2.0/2.1 record functionality

2.8 Speed Control (must have)

2.8.1 It MUST be possible for user input to change the speed of media output playback.

2.8.2 It MUST be possible to map the values for speed control to the rate attribute of prosody

2.8.3 Values for speed controls MAY be specified as properties which follow the standard VoiceXML scoping model. Default values are specified at session scope. Values specified on the control element take priority over inherited properties.

2.9 Volume Control (must have)

2.9.1 It MUST be possible for user input to change the volume of media output playback.

2.9.1.1 Values for volume controls MAY be specified as properties which follow the standard VoiceXML scoping model. Default values are specified at session scope. Values specified on the control element take priority over inherited properties.

2.9.1.2 It MUST be possible to map the values for volume control to the volume attribute of prosody in SSML.

2.10 Media Recording (must have)

2.10.1 Recording Modes

Form item recording mode (Requirements section 2.10.1.1 and 2.10.1.2) captures media from the caller (only) during the collect phase of a dialog. Partial- and Whole-Session recording captures media from the caller, system, and/or called party (in the cases of a transferred endpoint) in a multichannel or single (mixed) channel recording. Duration of these recordings depends on the type.

2.10.1.1 Form Item equivalent (e.g. VoiceXML 2.0 <record>)

2.10.1.1.1 VoiceXML 3.0 MUST be able to record input from a user.

2.10.1.2 Utterance Recording

Utterance recording mode is recording that occurs during an ASR or SIV form item. The audio may be endpointed, usually by the speech engine.

2.10.1.2.1 VoiceXML 3.0 MUST support recording of a user's utterance during an form item [recordutterance]

2.10.1.2.2 VoiceXML 3.0 MUST support the control of utterance recording via a <property>.

2.10.1.2.3 VoiceXML 3.0 MUST support the control of utterance recording via an attribute on input items.

2.10.1.3 Session Recording

Recording configuration and parameter requirements are defined in Section 2.10.2.

2.10.1.3.1 VoiceXML 3.0 MUST be able to record part of a VoiceXML session.

2.10.1.3.2 VoiceXML 3.0 MUST be able to record an entire dialog.

2.10.1.4 Restricted Session Recording

2.10.1.5 Multiple instances

2.10.1.5.1 VoiceXML 3.0 MUST be able to support multiple simultaneous recordings of different types during a call.

2.10.2. Recording Configuration and Parameters

2.10.2.1 Recording starts when caller begins speaking

VoiceXML 3.0 must support dynamic start-of-recording based on when a caller starts to speak

Voice Activity Detection used to determine when to initiate recording. This feature can be disabled.

2.10.2.2 Initial silence interval cancels recording

VoiceXML 3.0 must support specification of an interval of silence at the beginning of the recording cycle to terminate recording [timeout].

2.10.2.3 Final silence ends recording

VoiceXML 3.0 must support specification of an interval of silence that indicates end of speech to terminate recording [finalsilence]

Voice Activity Detection used to determine when to stop recording. This feature can be disabled.

Finalsilence interval may be used to specify the amount of silent audio to be removed from the recording.

2.10.2.4 Maximum recording time

VoiceXML 3.0 must support specification of the maximum allowable recording time [maxtime].

2.10.2.5 Terminate recording via DTMF input

VoiceXML 3.0 must provide a mechanism to control DTMF termination of an active record [dtmfterm]

2.10.2.6 Grammar control: Modal operation

2.10.2.6.1 VoiceXML 3.0 MUST provide a mechanism to control whether non-local DTMF grammars are active during recording [modal]

2.10.2.6.2 VoiceXML 3.0 MUST provide a mechanism to control whether non-local speech recognition grammars are active during recording [modal]

2.10.2.7 Media format

VoiceXML 3.0 must enable specification of the media type of the recording [type]

2.10.2.8 Recording Indicator

2.10.2.8.1 VoiceXML 3.0 MUST optionally support playing a beep tone to the user before recording begins. [beep]

2.10.2.8.2 VoiceXML 3.0 MUST optionally support displaying a visual indication to the user before recording begins.

2.10.2.8.3 VoiceXML 3.0 MUST optionally support displaying a visual indication to the user during recording.

2.10.2.9 Channel Assignment

2.10.2.9.1 VoiceXML 3.0 MUST be able to record and store each media path independently.

2.10.2.9.2 VoiceXML 3.0 MUST enable each media path to be recorded in the same multi-channel file.

2.10.2.9.3 VoiceXML 3.0 MUST enable each media path to be recorded into separate files.

2.10.2.9.4 VoiceXML 3.0 MAY be able to mix all voice paths into a single recording channel.

2.10.2.10 Channel Groups

2.10.2.10.1 One or more channels within the same session MUST be controllable as a group.

These groups can be used to simultaneously apply other recording controls to more than one media channel (e.g. mute two channels simultaneously). Applies whether channels are in same file or in separate files (implies concept of group of channels *not* part of the same file).

A command to "start recording" must specify the details for that recording session:

2.10.2.11 Buffer Controls

2.10.2.11.1 VoiceXML 3.0 MUST provide a mechanism to enable additional recording time before the start of speaking ("pre" buffer)

2.10.2.11.2 VoiceXML 3.0 MUST provide a mechanism to enable specification of additional recording time after the end of speaking ("post" buffer).

2.10.2.11.3 VoiceXML 3.0 MAY provide a mechanism to enable specification of the pre and post recording duration.

The duration provided by the platform is up to the amount of audio the application requested. If that amount of audio is not available, the platform is required to provide the amount of audio that is available.

2.10.3.1 Audio Muting

2.10.3.1.1 VoiceXML 3.0 MUST enable muting of an audio recording at any time for a specified length of time or until otherwise indicated to un-mute.

2.10.3.1.2 Audio to insert while muting can optionally be specified via a URI.

2.10.3.1.3 Optionally record the mute duration either in the recorded data or in associated meta data (e.g. a mark (out of band) or via a log channel or some other method)

2.10.3.1.5 Mute MUST be controllable for each channel independently.

2.10.3.1.6 Mute MUST be controllable for all channels in a group.

2.10.3.2 Blanking

2.10.3.2.1 VoiceXML 3.0 MUST enable blanking of a video recording at any time for a specified length of time or until otherwise indicated to un-blank.

2.10.3.2.2 A video or still image to replace video stream while blanking can be optionally specified via a URI.

2.10.3.2.2.1 An error will be thrown in the case of platforms that cannot handle the media type referred to by the URI.

2.10.3.2.3 The media inserted by default MUST be the same length as the blank duration.

2.10.3.2.4 The video being inserted MUST optionally be specified to span a length less than the actual mute/un-mute duration.

2.10.3.2.5 Blanking MUST be controllable separately from other media channels.

2.10.3.3 Grouped Blanking and Muting

2.10.3.3.1 It MUST be possible to simultaneously blank video and mute audio that are in the same media group.

2.10.3.4 Pause and Resume

2.10.3.4.1 VoiceXML 3.0 MUST enable a recording to be paused until explicitly restarted.

2.10.3.4.2 VoiceXML 3.0 MUST enable an indicator to be optionally specified in the file to denote that recording was paused, then resumed.

2.10.3.4.3 VoiceXML 3.0 MAY optionally enable the notation of the pause duration either in the recorded data or in associated meta data (e.g. a mark (out of band) or via a log channel or some other method)

2.10.3.5 Arbitrary Start, Stop, Restart/append

2.10.3.5.1 VoiceXML 3.0 MUST be able to start a recording at any time.

2.10.3.5.2 VoiceXML 3.0 MUST be able to stop an active recording at any time.

2.10.3.5.3 VoiceXML 3.0 MUST be able to restart / append to a previously active recording at any time. (during the session via reference to the recording)

2.10.3.5.4 optionally record the pause duration either in the recorded data or in associated meta data (e.g. a mark (out of band) or via a log channel or some other method)

If a recording was stopped and uploaded, then later appended, the application will need to keep track of when to upload the new version.

2.10.4. Media types

2.10.4.1 Audio recording

2.10.4.1.1 VoiceXML 3.0 MUST be able to record an incoming audio stream.

2.10.4.2 Video recording

2.10.4.2.1 VoiceXML 3.0 MUST support recording of an incoming video stream.

2.10.4.2.2 VoiceXML 3.0 MUST support recording of an incoming video stream with synchronized audio.

2.10.4.3 Media Type specification

2.10.4.3.1 VoiceXML 3.0 MUST be able to set the format of the media type of the recording according to IETF RFC 4288 [RFC4288].

2.10.4.4 Media formats and codecs

2.10.4.4.1 VoiceXML 3.0 MUST support specification of the media format and corresponding codec.

2.10.4.5 Platform support of media types

2.10.4.5.1 VoiceXML 3.0 platforms MUST support all media types that are indicated as required by the VoiceXML 3.0 Recommendation (types to be determined).

Note: This does not mean all possible media types are supported on all platforms.

2.10.5. Media Processing

2.10.5.1 Media processing MAY occur either in real-time or as a post-processing function.

2.10.5.2 Tone Clamping

2.10.5.2.1 VoiceXML 3.0 MAY optionally provide a means to specify if DTMF tones are to be removed from the recording.

DEFAULT: If tone clamping is enabled, it is performed after recording has completed (not in real-time).

2.10.5.3 Audio Processing Mode

2.10.5.3.1 VoiceXML 3.0 MUST optionally provide a means to specify if automatic audio level controls (e.g. Dynamic Range Compression, Limiting, Automatic Gain Control (AGC), etc.) are to be applied to the recording or if the recording is to be raw.

2.10.6. Recording data

2.10.6.1 The following information MUST be reported after recording has completed.

2.10.7 Upload, Storage, Caching

2.10.7.1 Destination

2.10.7.1.1 VoiceXML 3.0 MUST support specification of the destination of the recording buffer [dest].

2.10.7.3 A local cache of the recording MUST be optionally available to the application (e.g. V2 semantics of form item)

2.10.7.4 It MUST be possible to specify the upload to be either a synchronous or asynchronous operation.

2.10.7.5 It MUST be possible to select the upload to be available realtime, at the end of the call, or indefinitely after the end of the call.

2.10.7.6 All modes other than indefinite upload shall expose any errors in recording or upload to the application.

2.10.8. Errors and Events

Errors and events as a result of media recording must be presented to the application

2.11 Media Formats

VoiceXML 3 MUST support these categories of media capabilities:

This does not imply platform support requirements. For example, a particular platform may support Audio Basic but not Audio Rich. Another might support Audio Rich but not all meta data elements.

2.12 Data Model (must have)

2.11 Submit Processing (must have)

3. Format Requirements

3.1 Flow Language (must have)

A flow control language will be developed in conjunction with VoiceXML 3.0 (i.e. SCXML)

3.1.1 The flow control language will allow the separation of business logic from media control and user interaction.

3.1.2 The flow control language will be able to invoke VoiceXML 3.0 scripts, passing data into them and receiving results back when the scripts terminate.

3.1.3 The flow control language will be suitable for use as an Interaction Manager in the Multimodal Architecture Framework.

3.1.4 The flow control language will be based on state-machine concepts.

3.1.5 The flow control language will be able to receive asynchronous messages from external entities.

3.1.6 The flow control language will be able to send messages to external entities.

3.1.7 The flow control language will not contain any media-specific concepts such as ASR or TTS.

3.2 Semantic Model Definition (must have)

3.2.1 The precise semantics of all VXML 3.0 tags MUST be provided

3.2.2 The semantic model MUST be the authoritative description of VXML 3.0 functionality

3.2.3 Different conformance profiles MUST be possible, but they MUST be defined in terms of the semantic model.

3.2.4 The semantic model descriptions of VXML 3.0 MUST be able to express all of the functionality of VXML 2.1

3.2.5 Extensions to VXML 3.0 SHOULD be able to build on the semantic model descriptions

4. Other Requirements

4.1 Consistent with other Voice Browser Working Group specs (must have)

4.1.1 Wherever similar functionality to that of another Voice Browser Working Group specification is available, this language MUST use a syntax similar to that used in the relevant specification.

4.1.2 For data that is likely to be represented in another Voice Browser Working Group markup language (eg., SRGS or EMMA) or used by another Voice Browser Working Group language, there MUST be a clear definition of the mapping between the two data representations.

4.1.3 It MUST be possible to pass Internet-related document and server information (caching parameters, xml:base, etc.) from this language to other VBWG language processors for embedded VBWG languages.

4.2 Consistent with other specs (XML, MMI, I18N, Accessibility, MRCP, Backplane Activities) (must have)

4.2.1 MRCP

4.2.1.1 This language MUST support a profile that can be implemented using MRCPv2.

4.2.1.2 Where possible, this language SHOULD remain compatible with MRCPv2 in terms of data formats (SRGS, SSML).

4.2.2. MMI

There must be at least one profile of VoiceXML 3.0 in which all of the following requirements are supported.

4.2.2.1 It MUST be possible for VoiceXML 3.0 implementations to receive, process, and generate MMI life cycle events. Some events maybe handled automatically, while others maybe under author control.

4.2.2.2 VoiceXML 3.0 MUST provide a way for the author to specify the exact functions required for the application such that the platform can allocate the minimum necessary resources.

4.2.2.3 VoiceXML 3.0 MUST be able to provide EMMA-formatted information inside the data field of MMI life cycle events.

4.2.2.4 VoiceXML 3.0 platforms MUST specify one or more event I/O processors for interoperable exchange of life cycle events. The Voice Browser Group requests public comment on what such event processors should be or whether they should be part of the language at all.

4.3 Simplify Existing VoiceXML Tasks (must have)

4.3.1 This language MUST provide a mechanism for authors to develop dialog managers (state-based, task-based, rule-based, etc.) that are easily used and configured by other authors.

4.3.2 This language MUST provide mechanisms to simplify authoring of these common tasks: (we need to collect a list of common tasks)

4.4 Maintain Functionality from Previous VXML Versions

4.4.1 New features added in VoiceXML 3.0 MUST be backward compatible with previous VoiceXML versions

4.4.1.1 Functionality available in VoiceXML 2.0 and VoiceXML 2.1 MUST be available in VoiceXML 3.0.

4.4.1.2 Applications written in VoiceXML 2.0/2.1 MUST be portable to VoiceXML 3.0 without losing application capabilities.

4.5 Address Change Requests from previous VoiceXML Versions (must have)

4.5.1 Deferred change requests from VXML 2.0 and 2.1 reevaluated for VXML 3.0

In particular, the following deferred CRs reevaluated: R51, R92, R104, R113, R145, R155, R156, R186, R230, R233, R348, R394, R528, R541, and R565.

4.5.2 Unassigned change requests from VXML 2.0 and 2.1 reevaluated for VXML 3.0

In particular, the following unassigned CRs reevaluated: R600, R614, R619, R620, R622, R623, R624, R625, R626, R627, R628, R629, R631, and R632.

5. Acknowledgments

Appendix A. Previous Requirements

The following requirements have been satisfied by previous Voice Browser Working Group Specifications

A.1.1 Audio Modality Input and Output (must have) FULLY COVERED

The markup language can specify which spoken user input is interpreted by the voice browser, as well as the content rendered as spoken output by the voice browser.

Requirement Coverage

A.1.2 Sequential multi-modal Input (must have) FULLY COVERED

The markup language specifies that user input from multiple modalities is to be interpreted by the voice browser. There is no requirement that the input modalities are simultaneously active. For example, a voice browser interpreting the markup language in a telephony environment could accept DTMF input in one dialog state, and spoken input in another.

Requirement Coverage

A.1.3 Unco-ordinated, Simultaneous, Multi-modal Input (should have) FULLYCOVERED

The markup language specifies that user input from different modalities is to be interpreted at the same time. There is no requirement that interpretation of the input modalities are co-ordinated. For example, a voice browser in a desktop environment could accept keyboard input or spoken input in same dialog state.

Requirement Coverage

<field> defining multiple <grammar>s with different mode attribute values VoiceXML 2.0

A.1.4 Co-ordinated, Simultaneous Multi-modal Input (nice to have) FULLYCOVERED

The markup language specifies that user input from multiple modalities is interpreted at the same time and that interpretation of the inputs are co-ordinated by the voice browser. For example, in a telephony environment, the user can type200 on the keypad and say transfer to checking account and the interpretations are co-ordinated so that they are understood as transfer 200 to checking account.

Requirement Coverage

<field> defining multiple <grammar>s with different mode attribute values VoiceXML 2.0

A.1.5 Sequential multi-modal Output (must have) FULLY COVERED

The markup language specifies that content is rendered in multiple modalities by the voice browser. There is no requirement the output modalities are rendered simultaneously. For example, a voice browser could output speech in one dialog state, and graphics in another.

Requirement Coverage

A.1.6 Unco-ordinated, Simultaneous, Multi-modal Output (nice to have)FULLY COVERED

The markup language specifies that content is rendered in multiple modalities at the same time. There is no requirement the rendering of output modalities are co-ordinated. For example, a voice browser in a desktop environment could display graphics and provide audio output at the same time.

Requirement Coverage

A.1.7 Co-ordinated, Simultaneous Multi-modal Output (nice to have) FULLYCOVERED

The markup language specifies that content is to be simultaneously rendered in multiple modalities and that output rendering is co-ordinated. For example, graphical output on a cellular telephone display is co-ordinated with spoken output.

Requirement Coverage

A.2.1 Mixed Initiative: Form Level (must have) FULLY COVERED

Mixed initiative refers to dialog where one participant take the initiative by, for example, asking a question and expects the other participant to respond to this initiative by, for example, answering the question. The other participant, however, responds instead with an initiative by asking another question. Typically, the first participant then responds to this initiative, before the second participant responds to the original initiative. This behavior is illustrated below:

S-A1: When do you want to fly to Paris?
U-B1: What did you say?
S-B2: I said when do you want to fly to Paris?
U-A2: Tuesday.

where A1 is responded to in A2 after a nested interaction, or sub-dialog in B1 and B2. Note that the B2 response itself could have been another initiative leading to further nesting of the interaction.

The form-level mixed initiative requirement is that the markup language can specify to the voice browser that it can take the initiative when user expects a response, and also allow the user to take the initiative when it expects a response where the content of these initiatives is relevant to the task at hand, contains navigation instructions or concerns general meta-communication issues. This mixed initiative requirement is particularly important when processing form input (hence the name) and is further elaborated in requirements A.2.1.1, A.2.1.2, A.2.1.3 and A.2.1.4 below.

Requirement Coverage

A.2.1.1 Clarification Subdialog (must have) FULLY COVERED

The markup language can specify that a clarification sub-dialog should be performed when the user provides incomplete, form-related information. For example, in a flight enquiry service, the departure city and date may be required but the user does not always provide all the information at once:

S1: How can I help you?
U1: I want to fly to Paris.
S2: When?
U1: Monday

U1 is incomplete (or 'underinformative') with respect to the service (or form) and the system then initiates a sub-dialog in S2 to collect the required information. If additional parameters are required, further sub-dialogs may be initiated.

Requirement Coverage

A.2.1.2 Confirmation Subdialog (must have) FULLY COVERED

The markup language can specify that a confirmation sub-dialog is to be performed when the confidence associated with the interpretation of the user input is too low.

U1: I want to fly to Paris.
S1: Did you say 'I want a fly to Paris'?
U2: Yes.
S2: When?
U3: ...

Requirement Coverage

A.2.1.3 Over-informative Input: corrective (must have) FULLY COVERED

The markup language can specify that unsolicited user input in a sub-dialog which corrects earlier input is to be interpreted appropriately. For example, in a confirmation sub-dialog users may provide corrective information relevant to the form:

S1: Did you say you wanted to travel from Paris?
U1: No, from Perros. (modification)
U1': Yes, from Paris (repetition)

Requirement Coverage

A.2.1.4 Over-informative Input: additional (nice to have) FULLYCOVERED

The markup language can specify that unsolicited user input in a sub-dialog which is not corrective but additional, relevant information for the current form is to be interpreted appropriately. For example, in a confirmation sub-dialog users may provide additional information relevant to the form:
S1: Did you say you wanted to travel from Paris?
U1: Yes, I want to fly to Paris on Monday around 11.30

Requirement Coverage

A.2.2 Mixed Initiative: Task Level (must have) FULLY COVERED

The markup language needs to address mixed initiative in dialogs which involve more than one task (or topic). For example, a portal service may allow the user to interact with a number of specific services such as car hire, hotel reservation, flight enquiries, etc, which may be located on the different web sites or servers. This requirement is further elaborated in requirements A.2.2.1, A.2.2.2, A.2.2.3, A.2.2.4 and A.2.2.5 below.

A.2.2.1 Explicit Task Switching (must have) FULLY COVERED

The markup language can specify how users can explicitly switch from one task to another. For example, by means of a set of global commands which are active in all tasks and which take the user to a specific task; e.g. Take me to car hire, Go to hotel reservations.

Requirement Coverage

A.2.2.2 Implicit Task Switching (should have) FULLY COVERED

The markup language can specify how users can implicitly switch from one task to another. For example, by means of simply uttering a phrases relevant to another task; I want to reserve a McLaren F1 in Monaco next Wednesday.

Requirement Coverage

A.2.2.3 Manual Return from Task Switch (must have) FULLY COVERED

The markup language can specify how users can explicitly return to a previous task at any time. For example, by means of global task navigation commands such as previous task.

Requirement Coverage

A.2.2.4 Automatic Return from Task Switch (should have) FULLY COVERED

The markup language can specify that users can automatically return to the previous task upon completion or explicit cancellation of the current task.

Requirement Coverage

A.2.2.5 Suspended Tasks (should have) FULLY COVERED

The markup language can specify that when task switching occurs the previous task is suspended rather than canceled. Thus when the user returns to the previous task, the interaction is resumed at the point it was suspended.

Requirement Coverage

A.2.3 Help Behavior (should have) FULLY COVERED

The markup language can specify help information when requested by the user. Help information should be available in all dialog states.
S1: How can I help you?
U1: What can you do?
S2: I can give you flight information about flights between major cities world-wide just like a travel agent. How can I help you?
U1: I want a flight to Paris ...

Help information can be tapered so that it can be elaborated upon on subsequent user requests.

Requirement Coverage

A.2.4 Error Correction Behavior (must have) FULLY COVERED

The markup language can specify how error events generated by the voice browser are to be handled. For example, by initiating a sub-dialog to describe and correct the error:
S1: How can I help you?
U1: <audio but no interpretation>
S2: Sorry, I didn't understand that. Where do you want to travel to?
U2: Paris

The markup language can specify how specific types of errors encountered in spoken dialog, e.g. no audio, too loud/soft, no interpretation, no audio, internal error, etc, are to be handled as well as providing a general 'catch all' method.

Requirement Coverage

A.2.5 Timeout Behavior (must have) FULLY COVERED

The markup language can specify what to do when the voice browser times out waiting for input; for example, a timeout event can be handled by repeating the current dialog state:
S1: Did you say Monday?
U1: <timeout>
S2: Did you say Monday?

Note that the strategy may be dependent upon the environment; in a desktop environment, repetition for example may be irritating.

Requirement Coverage

A.2.6 Meta-Commands (should have) FULLY COVERED

The markup language specifies a set of meta-command functions which are available in all dialog states; for example, repeat, cancel, quit, operator, etc.

The precise set of meta-commands will be co-ordinated with the Telephony Speech Standards Committee.

The markup language should specify how the scope of meta-commands like 'cancel' is resolved.

Requirement Coverage

A.2.7 Barge-in Behavior (should have) FULLY COVERED

The markup language specifies when the user is able to bargein on the system output, and when it is not allowed.

Note: The output device may generate timestamped events when barge-in occurs (see 3.9).

Requirement Coverage

A.2.8 Call Transfer (should have) FULLY COVERED

The markup language specifies a mechanism to allow transfer of the caller to another line in a telephony environment. For example, in cases of dialog breakdown, the user can be transferred to an operator (cf. 'callto' in HTML). The markup language also provides a mechanism to deal with transfer failures such as when the called line is busy or engaged.

Requirement Coverage

A.2.9 Quit Behavior (must have) FULLY COVERED

The markup language provides a mechanism to terminate the session (cf. user-terminated sessions via a 'quit' meta-command in 2.6).

Requirement Coverage

A.2.10 Interaction with External Components (must have) FULLY COVERED

The markup language must support a generic component interface to allow for the use of external components on the client and/or server side. The interface provides a mechanism for transferring data between the markup language's variables and the component. Examples of such data are: configuration parameters (such as timeouts), and events for data input and error codes. Except for event handling, a call to an external component does not directly change the dialog state, i.e. the dialog continues in the state from which the external component was called.

Examples of external components are pre-built dialog components and server scripts. Pre-built dialogs are further described in Section A.3.3. Server scripts can be used to interact with remote services, devices or databases.

Requirement Coverage

A.3.1 Ease of Use (must have) FULLY COVERED

The markup language should be easy for designers to understand and author without special tools or knowledge of vendor technology or protocols (dialog design knowledge is still essential).

Requirement Coverage

A.3.2 Simplicity and Power (must have) FULLY COVERED

The markup language allows designers to rapidly develop simple dialogs without the need to worry about interactional details but also allow designers to take more control over interaction to develop complex dialogs.

Requirement Coverage

A.3.3 Support for Modularity and Re-use (should have) FULLY COVERED

The markup language complies with the requirements of the Reusable Dialog Components Subgroup.

The markup language can specify a number of pre-built dialog components. This enables one to build a library of reusable 'dialogs'. This is useful for handling both application specific input types, such as telephone numbers, credit card number, etc as well as those that are more generic, such as times, dates, numbers, etc.

Requirement Coverage

A.3.4 Naming (must have) FULLY COVERED

Dialogs, states, inputs and outputs can be referenced by a URI in the markup language.

Requirement Coverage

A.3.5 Variables (must have) FULLY COVERED

Variables can be scoped within namespaces: for example, state-level, dialog-level, document-level, application-level or session-level. The markup language defines the precise scope of all variables.

Variables can be assigned default values. Assignment may be optional; for example, in a flight reservation form, a 'special meal' variable need not be assigned a value by the user.

The precise requirements on variables may be affected by W3C work on modularity and XML schema datatypes.

Requirement Coverage

A.3.6 Variable Binding (must have) FULLY COVERED

User input can bind one or more state variables. A single input may bind a single variable or it may bind multiple variables in any order; for example, the following utterances result in the same variable bindings

Requirement Coverage

A.3.7 Event Handler (must have) FULLY COVERED

The markup language provides an explicit event handling mechanism for specifying actions to be carried out when events are generated in a dialog state.

Event handlers can be ordered so that if multiple event handlers match the current event, only the handler with the highest ranking is executed. By default, event handler ranking is based on proximity and specificity: i.e. the handler closest in the event hierarchy with the most specific matching conditions.

Actions can be conditional upon variable assignments, as well as the type and content of events (e.g. input events specifying media, content, confidence, and so on).

Actions include: the binding of variables with information, for example, information contained in events; transition to another dialog state (including the current state).

Requirement Coverage

A.3.8 Builtin Event Handlers (should have) FULLY COVERED

The markup language can provide implicit event handlers which provide default handling of, for example, timeout and error events as well as handlers for situations, such as confirmation and clarification, where there is a transition to a implicit dialog state. For example, there can be a default handler for user input events such that if the recognition confidence score is below a given threshold, then the input is confirmed in a sub-dialog.

Properties of implicit event handlers (thresholds, counters, locale, etc) can be explicitly customized in the markup language.

Requirement Coverage

A.3.9 Output Content and Events (must have) FULLY COVERED

The markup language complies with the requirements developed by the Speech Synthesis Markup Subgroup for output text content and parameter settings for the output device. Requirements on multimodal output will be co-ordinated by the Multimodal Interaction Subgroup (cf. Section 1).

In addition, the markup supports the following output features (if not already defined in the Synthesis Markup):

The output device generates timestamped events including error events and progress events (output started/stopped, current position).

Requirement Coverage

A.3.10 Richer Output (nice to have) FULLY COVERED

The markup language allows for richer output than variable substitution in the output content. For example, natural language generation of output content.

Requirement Coverage

A.3.11 Input Content and Events (must have) FULLY COVERED

The markup language complies with the requirements developed by the Grammar Representation Subgroup for the representation of speech grammar content. Requirements on multimodal input will be co-ordinated by the Multimodal Interaction Subgroup (cf. Section 1).

The markup language can specify the activation and deactivation of multiple speech grammars. These can be user-defined, or builtin grammars (digits, date, time, money, etc).

The markup language can specify parameters for speech grammar content including timeout parameters --- maximum initial silence, maximum utterance duration, maximum within-utterance pause --- energy thresholds necessary for bargein, etc.

The input device generates timestamped events including input timeout and error events, progress events (utterance started, interference, etc), and recognition result events (including content, interpretation/variable bindings, confidence).

In addition to speech grammars, the markup language allows input content and events to be specified for DTMF and keyboard devices.

Requirement Coverage

timeout, completetimeout, incompletetimeout, interdigittimeout, termtimeout properties VoiceXML 2.0

application.lastresult$.interpretation, application.lastresult$.confidence VoiceXML 2.0

A.4.1 Event Handling (must have) FULLY COVERED

One key difference between contemporary event models (e.g. DOM Level 2, 'try-catch' in object-oriented programming) is whether the same event can be handled by more than one event handler within the hierarchy. The markup language must motivate whether it supports this feature or not.

A.4.2 Logging (nice to have) FULLY COVERED

For development and testing it is important that data and events are to be logged by the voice browser. At the most detailed level, this will include logging of input and output audio data. A mechanism which allows logged data to be retrieved from a voice browser, preferably via standard Internet protocol (http, ftp, etc), is also required.

One approach is to require that the markup language can control logging via, for example, an optional meta tag. Another approach is for logging to be controlled by means other than the markup language, such as via proprietary meta tags.

Feature Requirement / Recording type	Dialog	Utterance	Session	Restricted Session
2.10.2.1 Recording starts when caller begins speaking	Y	Y	N	N
2.10.2.2 Initial silence interval cancels recording	Y	N	N	N
2.10.2.3 Final silence ends recording	Y	N	N	N
2.10.2.4 Maximum recording time	Y	N	N	N
2.10.2.5 Terminate recording with DTMF input	Y	N	N	N
2.10.2.6 Grammar control: modal operation	Y	N	N	N
2.10.2.7 Media format	Y	Y	Y	Y
2.10.2.8 Recording indicator	N	N	Y	N
2.10.2.9 Channel assignment	N	N	Y	Y
2.10.2.10 Channel groups	N	N	Y	Y
2.10.2.11 Buffer control	Y	Y	N	N