Abstract
This document describes CCXML, or the Call Control eXtensible Markup Language. CCXML is designed to provide
telephony call control support for dialog systems, such as VoiceXML
[VOICEXML]. While
CCXML can be used with any dialog systems capable of handling media, CCXML has been designed to complement and
integrate with a VoiceXML interpreter. Because of this there are many references to VoiceXML's capabilities and
limitations. There are also details on how VoiceXML and CCXML can be integrated. However, it should be noted that the
two languages are separate and are not REQUIRED in an implementation of either language. For
example, CCXML could be integrated with a more traditional Interactive Voice Response (IVR) system
or a 3GPP Media Resource Function (MRF), and VoiceXML or other dialog systems could be
integrated with some other call control systems.
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 specification describes the Call Control XML (CCXML) markup language that is designed to provide telephony
call control support for VoiceXML or other dialog systems. 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 (
W3C Members only ).
This second last call working draft addresses many of the comments that came up
during the last call review. Feedback was received on the public working group mailing
list and via the internal working group reviews. Some of the changes include:
- Better documentation of the ccxml.kill events
- Clean up of the fetch/goto/createccxml framework
- Consistent formatting of element attribute tables
- Cleanup of media duplex model
- Addition of a writeable application scope.
- Changes the script element to allow statically compiled scripts
- Better definition of the event handling algorithm
- Removed regular expressions from event names on transition
- Better definition of move
- Updated conference object
- Added merge element
For a detailed list please see Changes in Last Call Working Draft 2.
This is a W3C Last Call Working Draft
for review by W3C Members and other interested parties. Last Call means that the Working Group believes that this
specification is technically sound and therefore wishes this to be the Last Call for comments. If the feedback is
positive, the Working Group plans to submit it for consideration as a W3C Candidate Recommendation. Comments can be
sent until 31 January 2005.
A Implementation Report Plan is currently being developed for this specification. The Working Group
currently expects to require at least two independently developed interoperable implementations of each required
feature, and at least one implementation of each feature, in order to exit the next phase of this document, the
Candidate Recommendation phase. To help the Voice Browser Working Group build such a report, reviewers are encouraged
to implement this specification and to indicate to W3C which features have been implemented, and any problems that
arose.
This document is for public review. Comments and discussion are welcomed on the public mailing list <
www-voice@w3.org >. 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). The
archive for the list is accessible on-line.
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.
This document has been produced under the 24
January 2002 CPP as amended by the W3C Patent Policy
Transition Procedure. An individual who has actual knowledge of a patent which the individual believes contains
Essential Claim(s) with respect to this specification should disclose the information in accordance with section 6 of
the W3C Patent Policy. Patent
disclosures relevant to this specification may be found on the Working Group's
patent disclosure page.
Conventions of this Document
In this document, the key words "must", "must not", "required", "shall", "shall not", "should", "should not",
"recommended", "may", and "optional" are to be interpreted as described in [RFC2119] and indicate requirement levels for compliant VoiceXML implementations.
Table of Contents
1: Introduction
This document describes CCXML, the Call Control eXtensible Markup Language. CCXML provides declarative markup to
describe telephony call control. CCXML is a language that can be used with a dialog system
such as VoiceXML [VOICEXML].
CCXML can provide a complete telephony service application, comprised of Web server
CGI compliant application logic, one or more CCXML documents to
declare and perform call control actions, and to control one or more dialog applications that perform user media
interactions
Since platforms implementing CCXML MAY choose to use one of many telephony call control
definitions ( JAIN Call Control [ JSR021 ], ECMA CSTA [
CSTA ], S.100 [ S.100 ], etc.), the call
control model in CCXML has been designed to be sufficiently abstract so that it can accommodate all major
definitions. For relatively simple types of call control, this abstraction is straightforward. The philosophy in this
regard has been to "make simple things simple to do." Outdial, transfer (redirect), two-party bridging, and many
forms of multi-party conferences fall within this classification.
Figure 1 shows the architecture of a telephony implementation consisting of three primary components:
- a caller (along with the telephone network),
- a dialog system (e.g. a VoiceXML
implementation),
- and the CCXML implementation which manages the Connections between the first two components.
The Telephony Web Application may or may not be integrated with the Voice Web Application.
The Telephony Control and Dialog Control Interfaces may be implemented as an API or protocol.
The components as shown in the figure below represent logical functions, and are not meant to imply any particular
architecture.
Figure 1
2: Motivation (Informative)
CCXML is designed to complement dialog systems such as VoiceXML by providing
advanced telephony functions. It also can be used as a third-party call control manager in any telephony system. This
document contains references to VoiceXML's capabilities and limitations, as well as details on how VoiceXML and CCXML
can be integrated.
The CCXML specification originated from the desire to handle call control requirements that were beyond the scope
of the VoiceXML specification. The following requirements are addressed by this specification:
- Support for multi-party conferencing, with advanced conference and audio control. A
conferencing application involves multiple participants, and is dependent upon call control to establish
relationships between those participants.
- The ability to give each active call leg its own dedicated VoiceXML interpreter. For example, in VoiceXML, the
second leg of a transferred call lacks a VoiceXML interpreter of its own, limiting the scope of possible
applications.
- Sophisticated multiple-call handling and control, including the ability to place outgoing calls.
- Handling for a richer class of asynchronous events. Advanced telephony operations involve substantial amounts
of signals, status events, and message-passing. VoiceXML 2.0 does not integrate
asynchronous "external" events into its event-processing model.
- The ability to receive events and messages from external computational entities. Interacting with an outside
call queue, or placing calls on behalf of a document server, means that VoiceXML must have additional external
interfaces.
CCXML and VoiceXML implementations are not mutually dependent. A CCXML implementation may or may not support voice
dialogs, or may support dialog languages other than VoiceXML.
3: Concepts and Architecture
A CCXML application consists of a collection of CCXML documents that control
and manage the objects listed below:
- CCXML Session: A CCXML session is comprised of an executing CCXML
document, or sequence of CCXML documents; each concurrently executing CCXML document is a separate session, and can
be uniquely identified and referenced.
- Connection: Connections can be "call legs" (real-world phone
connections) or system resources to facilitate interaction with a voice dialog. Media
streams between Connections, or between Connections and
Conference objects, need to be tracked by the CCXML
interpreter and will take real system resources, but do not need a dedicated identifier because they are
identified by their endpoints. Ownership of Connections can be moved from one session
to another using
<move>.
- Conference object: A Conference Object models a resource for
mixing media streams. In order to accommodate the widest range of underlying telephony call control definitions,
CCXML assumes a separate Conference Object, realizing that this abstraction may not
have a direct counterpart in all telephony platforms. See
<createconference> and
<destroyconference> for further information.
- Voice Dialog: When active, a Voice Dialog is associated with a
specific Connection by which the Voice Dialog may interact
with one-way or two-way media streams from other Connections or a
Conference Object.
CCXML programs manipulate these entities through elements defined in the CCXML language. They can also send and/or
receive asynchronous events (mentioned above) associated with these entities.
CCXML programs directly manipulate Connection Objects and
Conference Objects with various elements in the language, such as
<accept>, <createconference>, and <join>. CCXML may also
receive events from Connection and Conference Objects, in
the case of line signaling, line-status informational messages, or error and failure scenarios.
Connections and Conference Objects do not accept events;
CCXML must use the builtin elements to direct them.
CCXML programs can start and kill Voice Dialogs using language elements. It can receive
events from Voice Dialogs, which may be standardized events such as
dialog.exit, or application-specific ones. CCXML can support sending of an event to a
Voice Dialog.
CCXML programs can create other CCXML sessions using <createccxml>.
This is the only guaranteed control mechanism a CCXML Session ever wields over another.
Any other interaction takes place through the event mechanism. CCXML Sessions can both
send and receive events between one another.
3.1: Event Processing
Telephone applications need to receive and process large numbers of events in real-time. These events arrive from
outside the program itself - either the underlying telephony platform, or from other sources of events.
A CCXML program includes event handlers which are executed when certain events arrive. There are mechanisms for
passing information back and forth between Voice Dialogs (such as VoiceXML) and CCXML, but
the important points are that CCXML:
- lives on its own thread, and
- carries the burden of rapid asynchronous event handling
Note: References to threads are meant as logical threads and do not imply any specific platform
implementation.
3.2: Conferencing
CCXML provides a powerful and flexible method of creating multi-party calls based on on the following
concepts:
- Call legs are audio sinks and sources which can be combined to form arbitrary networks.
- A conference is an audio stream that mixes together all the speakers' audio outputs. CCXML conference networks
allow for conference objects, which mix inputs into a single output channel.
- A conference can include splitters, which take a single input channel and emit it over several outputs.
- A conference's architecture may be modified dynamically, thus allowing for moderation, floor control, mute,
etc.
- Conferencing technology is implementation-dependent. CCXML implementations may not support all conferencing
features mentioned above.
3.3: Scripting
The computational semantics of CCXML language is based on the ECMAScript Compact Profile (ES-CP, also known as
ECMA-327) [ECMA327]. ES-CP is a strict subset of the third edition of ECMA-262
[ECMASCRIPT]. Execution efficiency is a primary goal of CCXML
implementations, and ES-CP was chosen to ensure that CCXML implementations can operate in a variety of execution
environments and without excessive execution overhead.
The ES-CP document specification states:
'ECMAScript Compact Profile is a subset of ECMAScript 3rd Edition tailored to resource-constrained devices such as
battery powered embedded devices. Therefore, special attention is paid to constraining ECMAScript features that
require proportionately large amounts of system memory (both for storing and executing the ECMAScript language
features) and continuous or proportionately large amounts of processing power.'
While CCXML implementations are not necessarily intended for battery powered embedded devices, it is intended to
be used in large, real-time telephony platforms managing thousands of lines. The constraints of ES-CP emphasize
CCXML's ongoing concern for execution efficiency.
Even though ES-CP tends to be implemented using interpreters, CCXML does not require an interpretive
implementation. ES-CP can be compiled to a target language such as C, and thus in turn to machine code, so that CCXML
documents which are static can be rendered once in machine code. For example, a CCXML implementation, for
optimization purposes, could translate and compile frequently used CCXML documents on their way from the document
server to the CCXML execution environment in order to avoid multiplying interpretive overhead by the number of lines
that execute the same document.
The emphasis on efficiency in CCXML language is also shown by the avoidance of requirements which can only be
implemented either by interpretation or by run-time evaluation.
The choice of an implementation strategy is up to the CCXML implementer and CCXML language is aimed to allow a
range of design choices in order to accommodate implementations on a wide variety of platforms.
A CCXML implementation MUST support the ECMAScript Compact Profile.
3.4: Definitions
The following terms, which are used throughout this specification, are defined as:
-
ECMAScript left-hand-side expression - defined in ECMA-262
[ECMASCRIPT] 11.2; this is an expression which produces a result to
which a value can be assigned; an expression which is valid as the left hand operand of an assignment (=)
operator;
Several examples of left-hand-side expressions are as follows (left-hand-side expression in red):
<?xml version="1.0" encoding="UTF-8"?>
<ccxml version="1.0" xmlns="http://www.w3.org/2002/09/ccxml">
<script>
simpleVar = 'Simple Expr';
arrayVar[0] = 'Simple Expr';
arrayVar['arrayKey'] = 'Simple Expr';
arrayVar = {callingDevice: 'notSpecified', callCharacteristics: 'voiceUnitCall'};
</script>
</ccxml>
-
ECMAScript expression - defined in ECMA-262
[ECMASCRIPT] 11.1; this is an expression which produces a value; an
expression which is valid on the right hand side of an assignment operator;
Several examples of ECMAScript expressions are as follows (ECMAScript expression in red):
<?xml version="1.0" encoding="UTF-8"?>
<ccxml version="1.0" xmlns="http://www.w3.org/2002/09/ccxml">
<script>
simpleVar = 'hello world'; // simple string expression
simpleVar = 'hello world'.length; // Calling a method that returns a
// number on the simple string object
simpleVar = 5; // Simple number expression
simpleVar = array[0]; // Array position expression
simpleVar = array['key']; // Array named value expression
simpleVar = myCoolFunction(); // Function return expression
</script>
</ccxml>
-
ECMAScript variable name - defined in ECMA-262
[ECMASCRIPT] 7.6; this is any valid sequence of characters, known as
an identifier, which can be used as a variable name, a property name, or a function name; this does not include
any qualifiers, such as array or property accessors;
Several examples of ECMAScript variable names are as follows (ECMAScript variable name in red):
<?xml version="1.0" encoding="UTF-8"?>
<ccxml version="1.0" xmlns="http://www.w3.org/2002/09/ccxml">
<script>
simpleVar = 'Simple Expr';
arrayVar[0] = 'Simple Expr';
arrayVar['arrayKey'] = 'Simple Expr';
arrayVar = {callingDevice: 'notSpecified', callCharacteristics: 'voiceUnitCall'};
</script>
</ccxml>
- Empty ECMAScript object - an object returned by the
new Object() ECMAScript
expression; an object with no properties.
- CCXML variable name - a variable name, with optional dot separated qualification, declared in
a CCXML
<var> element or defined within ECMAScript code using the var keyword.
- Scope element - a CCXML variable name which defines a variable scope;
<ccxml> and <transition> are CCXML scope elements. Variables which are
defined within a scope element are not visible to variables defined in other scope elements.
-
Time interval - CCXML uses the Cascading Style Sheets, Level 2 [
CSS2 ] time format. 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".
- CCXML Application/Program - A collection of CCXML documents that
together create a complete application/program.
- CCXML Interpreter - The software that processes CCXML documents,
executes commands and dispatches events. Also referred to as the "CCXML Platform".
3.5: Session Life-Cycle
3.5.1: Startup
A CCXML session can be started for the following reasons:
- A new incoming phone call coming into the platform.
- A CCXML application executing a
<createccxml>.
- An external session launch request coming into the platform.
When a session is started due to an incoming call it has ownership of the event endpoint associated with the new
Connection. The new CCXML session will be responsible for processing the Connection state events and performing the
Connection actions. If the session was started because of a <createccxml>, it will start without
ownership of any event endpoints unless an event was forwarded using the start attribute of
<createccxml>, in which case the associated event endpoint would then be owned by the new CCXML
session. In the case of an external session launch the session will not own any event endpoints.
A CCXML application can determine the reason its session was started by evaluating the contents of the
session.startupmode session variable that is defined in the Session
Variables section.
3.5.2: Shutdown
A CCXML session can end in one of the following ways:
- The CCXML application executes an
<exit>.
- An unhandled
"error.*" event.
- An unhandled
"ccxml.kill" event.
- A
"ccxml.kill.unconditional" event.
When a CCXML session ends, all active connections, conferences and dialogs that are owned by that session are
automatically terminated by the platform.
3.5.3: Session Life-Cycle Diagrams
The following diagrams illustrate the session life-cycle of several different scenarios. These diagrams do not
show all possible scenarios but rather show some of the most common ones that CCXML applications may encounter.
3.5.3.1: session can live before and after active connections (or no connections
at all)
A CCXML session does not necessarily need to have any connections associated with it. After starting, a session
may acquire connections as a result of <createcall> or <move>
requests.
3.5.3.2: connection life shorter than session
In this example, the session is started due to an incoming call. A connection is typically shorter than a session.
A session does not end when a connection terminates.
3.5.3.3: session ends, kills all active connections
When a session ends, any resources, including connections owned by that session are
terminated.
3.5.3.4: session can have multiple sequential connections
A session can have multiple sequential connections
3.5.3.5: session can have multiple sequential connections and multiple concurrent
connections
In addition to having multiple sequential connections, a session can have multiple concurrent
connections.
3.5.3.5: move a connection to a newly created session
A connection can be moved from one CCXML session to another session. In the figure below, CCXML session (1)
creates a new CCXML session (2) via <createccxml>. Then, the connection is moved from the original
CCXML session to the new session.
3.5.3.7: move a connection to a "master" session
A connection can be moved from one CCXML session to another session, such as a "master"
session.
3.5.3.8: optional "master" session for inbound call handling
Implementations MAY, as a platform-specific optimization, choose to
deliver more than one inbound call to a single "master" session. This is can be viewed as equivalent to several
sessions performing a <move>, as described in 3.5.3.7, of the connection.alerting
event to a single CCXML session.
The default inbound call handling behavior for CCXML implementations is to create a new CCXML
session and deliver the connection.alerting event to it. If a platform supports delivery of multiple
inbound calls to a single session, the way this is configured is implementation specific.
3.5.3.9: ccxml.kill.unconditional event raised
If at anytime a ccxml.kill.unconditional event is raised by the underlying
implementation, the CCXML session is immediately terminated and all active connections, conferences and dialogs that
are owned by that session are automatically terminated by the platform.
3.5.3.10: Normal session shutdown requested by the platform
If at anytime the platform wishes to terminate a CCXML session it MUST
raise a ccxml.kill event to inform the CCXML application. The normal response to this event is for the
CCXML application to perform any clear up and termination of current active connections, conferences or dialogs and
then execute an <exit> element.
If the CCXML application does not respond to the ccml.kill event in a timely manner
the platform MAY then raise a ccxml.kill.unconditional event to immediately
terminate the CCXML session and all active connections, conferences, and dialogs that are owned by the
session.
4: Simple Examples
4.1: Hello World
This simple CCXML document shows an example of a "hello world" application that is started due to an incoming call
where the application simply assigns a value to a variable, prints a message to the platform log and exits:
<?xml version="1.0" encoding="UTF-8"?>
<ccxml version="1.0" xmlns="http://www.w3.org/2002/09/ccxml">
<eventprocessor>
<transition event="connection.alerting" name="evt">
<var name="MyVariable" expr="'This is a CCXML Variable'"/>
<log expr="'Hello World. I just made a variable: ' + MyVariable"/>
<log expr="'Lets hang up on this incoming call.'"/>
<exit/>
</transition>
</eventprocessor>
</ccxml>
4.2: Accept or Reject a Call
This CCXML document shows an example of how to process a incoming call event and answer or reject the call based
on the phone number of the calling party:
<?xml version="1.0" encoding="UTF-8"?>
<ccxml version="1.0" xmlns="http://www.w3.org/2002/09/ccxml">
<eventprocessor>
<transition event="connection.alerting" name="evt">
<log expr="'The number called is' + evt.connection.remote + '.'"/>
<if cond="evt.connection.remote == 'tel:+18315551234'">
<log expr="'Go away! we do not want to answer the phone.'"/>
<reject/>
<else/>
<log expr="'We like you! We are going to answer the call.'"/>
<accept/>
</if>
</transition>
<transition event="connection.connected">
<log expr="'Call was answered,Time to disconnect it.'"/>
<disconnect/>
</transition>
<transition event="connection.disconnected">
<log expr="'Call has been disconnected. Ending CCXML Session.'"/>
<exit/>
</transition>
</eventprocessor>
</ccxml>
4.3: Simple Dialog
This is an example of running a simple VoiceXML dialog from CCXML. The application answers an incoming phone call
and then connects it to a VoiceXML dialog that returns a value that is then logged to the platform:
dialog.ccxml:
<?xml version="1.0" encoding="UTF-8"?>
<ccxml version="1.0" xmlns="http://www.w3.org/2002/09/ccxml">
<!-- Lets declare our state var -->
<var name="state0" expr="'init'"/>
<eventprocessor statevariable="state0">
<!-- Process the incoming call -->
<transition state="init" event="connection.alerting">
<accept/>
</transition>
<!-- Call has been answered -->
<transition state="init" event="connection.connected" name="evt">
<log expr="'Houston, we have liftoff.'"/>
<dialogstart src="'dialog.vxml'"/>
<assign name="state0" expr="'dialogActive'" />
</transition>
<!-- Process the incoming call -->
<transition state="dialogActive" event="dialog.exit" name="evt">
<log expr="'Houston, the dialog returned [' + evt.values.input + ']'" />
<exit />
</transition>
<!-- Caller hung up. Lets just go on and end the session -->
<transition event="connection.disconnected" name="evt">
<exit/>
</transition>
<!-- Something went wrong. Lets go on and log some info and end the call -->
<transition event="error.*" name="evt">
<log expr="'Houston, we have a problem: (' + evt.reason + ')'"/>
<exit/>
</transition>
</eventprocessor>
</ccxml>
dialog.vxml:
<?xml version="1.0"?>
<vxml xmlns="http://www.w3.org/2001/vxml" version="2.0">
<form id="Form">
<field name="input" type="digits">
<prompt>
Please say some numbers ...
</prompt>
<filled>
<exit namelist="input"/>
</filled>
</field>
</form>
</vxml>
5: CCXML Elements Listing
6: Document Control Flow and Execution
6.1: Overview
A CCXML session begins with the execution of a CCXML document. The flow of the execution can be changed with the
help of <if>, <elseif>, <else>, <fetch>,
and <goto>. Most of a CCXML session's execution will take place within an
<eventprocessor>, which processes a stream of incoming events.
A CCXML session can consist of multiple CCXML documents, traversed by use of <goto> and
<fetch>.
A new CCXML session has a new session object (session.*), where initially the length of the
connection array is 0. A CCXML session can contain multiple active connections.
A CCXML session may launch a new CCXML session using <createccxml>. The new CCXML session executes in an
independent context and variable space from the original CCXML session, completely independent of the lifetime of the
original session. Sessions can communicate by sending messages via <send>.
The media type application/ccxml+xml will be registered for CCXML documents.
The proposed definition of the media type is located in Appendix J: The CCXML
Media Type.
This media type should be used for a XML document containing CCXML content.
6.2: Elements
This section details the CCXML elements for control flow and execution.
6.2.1: <ccxml>
6.2.1.1: Overview
This is the parent element of a CCXML document and encloses the entire CCXML script in a document. When a
<ccxml> is executed, its child elements are collected logically together at the beginning of the
document and executed in document order before the target <eventprocessor>. This is called
document initialization.
The <ccxml> can designate the CCXML namespace. This can be achieved by declaring an
xmlns attribute or an attribute with an " xmlns " prefix. See [XMLNS] for details. Note that when the xmlns attribute is used alone, it sets the
default namespace for the element on which it appears and for any child elements. The namespace URI for CCXML is
"http://www.w3.org/2002/09/ccxml".
6.2.1.2: <ccxml> Attribute Details
| version | true | | string | none | 1.0 |
The version of this CCXML document. The initial version number is 1.0.
|
| xml:base | false | | valid URL | none | A valid URL
|
The base URI for this document as defined in [XML-BASE].
As in [HTML], a URI which all relative references within the
document take as their base.
|
6.2.2.1: Overview
The <metadata> and <meta> are containers in which information about the document can be placed. The
<metadata> provides more general and powerful treatment
of metadata information than <meta> by using a metadata
schema.
A <meta> declaration associates a string to
a declared meta property or declares " http-equiv " content. Either a
name or http-equiv attribute is REQUIRED.
It is an error to provide both name and http-equiv attributes. A
content attribute is REQUIRED. The seeAlso
property is the only defined <meta> property name. It is
used to specify a resource that might provide additional metadata information about the content. This property is
modelled on the
rdfs:seeAlso property
of Resource Description Framework (RDF) Schema Specification 1.0 [RDF-SCHEMA
§2.3.4]. The http-equiv attribute has a special significance when documents are
retrieved via HTTP. Although the preferred method of
providing HTTP header information is by using
HTTP header fields, the " http-equiv
" content MAY be used in situations where the CCXML document author is unable to configure
HTTP header fields associated with their document on the
origin server, for example, cache control information. Note that, as with <meta> in HTML documents
[HTML], HTTP servers and caches are
not REQUIRED to introspect the contents of <meta> in CCXML documents and thereby override the header values they would send
otherwise.
Informative: This is an example of how <meta> can be
included in a CCXML document to specify a resource that provides additional metadata information and also indicate
that the document MUST NOT be cached.
<?xml version="1.0" encoding="UTF-8"?>
<ccxml version="1.0"
xmlns="http://www.w3.org/2002/09/ccxml">
<meta name="seeAlso"
content="http://example.com/my-ccxml-metadata.xml"/>
<meta http-equiv="Cache-Control" content="no-cache"/>
</ccxml>
<meta> is an empty element.
6.2.2.2: <meta> Attribute Details
| name | false |
This attribute may not be specified in conjunction with the http-equiv attribute
| NMTOKEN | none | seeAlso
|
The NAME of the metadata property.
The seeAlso property is used to specify a resource that might provide additional metadata
information about the content.
Either the name or the http-equiv attribute has to be specified. If neither
of them is specified, or if both are specified, an error.fetch event will be thrown.
|
| http-equiv | false |
This attribute may not be specified in conjunction with the name attribute
| NMTOKEN | none |
A valid HTTP header
|
The NAME of an HTTP response header.
This attribute has special significance when documents are retrieved via HTTP. The http-equiv
content may be used in situations where the CCXML document author is unable to configure
HTTP header fields associated with their document on the origin server.
Either the name or the http-equiv attribute has to be specified. If neither
of them is specified, or if both are specified, an error.fetch event will be thrown.
|
| content | true | | string | none | |
The value of the metadata property.
|
6.2.3.1: Overview
<metadata> is a container in which
information about the document can be placed using a metadata language. Although any metadata language can be used
within <metadata>, it is
recommended that the Resource Description Format [RDF] be used in conjunction with the
general metadata properties defined by the Dublin Core Metadata Initiative [DC].
RDF [RDF-SYNTAX] is a declarative language and provides a standard way for using XML
to represent metadata in the form of statements about properties and relationships of items on the Web. A
recommended set of generally applicable metadata properties (e.g., " title ", "
creator ", " subject ", " description ", " copyrights ", etc.) is
the Dublin Core Metadata Element Set [DC], used in the example below.
Document properties declared with <metadata> can use
any metadata schema.
Informative: This is an example of how <metadata> can
be included in a CCXML document using the Dublin Core version 1.0 RDF schema [DC] describing
general document information such as title, description, date, and so on:
<?xml version="1.0" encoding="UTF-8"?>
<ccxml version="1.0"
xmlns="http://www.w3.org/2002/09/ccxml">
<metadata>
<rdf:RDF
xmlns:rdf = "http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc = "http://purl.org/dc/elements/1.1/">
<!-- Metadata about CCXML document -->
<rdf:Description rdf:about="http://www.example.com/meta.ccxml"
dc:title="Hamlet-like Soliloquy"
dc:description="Aldine's Soliloquy in the style of Hamlet"
dc:publisher="W3C"
dc:language="en"
dc:date="2002-11-29"
dc:rights="Copyright 2002 Aldine Turnbet"
dc:format="application/ccxml+xml" >
<dc:creator>William Shakespeare</dc:creator>
<dc:creator>Aldine Turnbet</dc:creator>
</rdf:Description>
</rdf:RDF>
</metadata>
</ccxml>
The following CCXML elements can occur within the content of <metadata> : none .
6.2.3.2: <metadata> Attribute Details
6.2.4: <if>
6.2.4.1: Overview
<if> is a container for conditionally executed elements. <else> and
<elseif> can optionally appear within an <if> as immediate children, and serve
to partition the elements within an <if>. <else> and
<elseif> have no content. <else/> is a synonym for <elseif
cond="true"/>.
Each partition within an <if> is preceded by an element having a cond attribute.
The initial partition is preceded by the <if> and subsequent partitions by
<elseif>s (or <else>s). The first partition in document order with a
cond that evaluates to true is selected. <else> always evaluate to
true. A partition MAY be empty.
If an <if> has no immediate <elseif> or <else> children,
the full contents of the <if> will be selected when the cond attribute is
true.
<else> was chosen to match similar concepts in other languages, and supports examples such
as
<if cond="...">
<!-- selected when <if cond> is true -->
<else/>
<!-- selected when <if cond> is false -->
</if>.
However, <else> is a synonym for <elseif cond="true"/>, so an example such
as
<if cond="...">
<!-- selected when <if cond> is true -->
<else/>
<!-- selected when <if cond> is false -->
<else/>
<!-- never selected -->
</if>
is also possible and SHOULD be interpreted as
<if cond="...">
<!-- selected when <if cond> is true -->
<elseif cond="true"/>
<!-- selected when <if cond> is false -->
<elseif cond="true"/>
<!-- never selected -->
</if>.
With this definition for <else>, a valid XML [XML]
document is also a valid CCXML document.
6.2.4.2: <if> Attribute Details
| cond | true | | ECMAScript Expression | none | A valid ECMAScript expression |
An ECMAScript expression which can be evaluated to true or false.
|
6.2.5: <elseif>
6.2.5.1: Overview
An <elseif> partitions the content of an <if>, and provides a condition that
determines the selection of the partition it begins. <elseif> can appear optionally as an
immediate child of an <if>.
6.2.5.2: <elseif> Attribute Details
| cond | true | | ECMAScript Expression | none | A valid ECMAScript expression |
An ECMAScript expression which can be evaluated to true or false.
|
6.2.6: <else>
6.2.6.1: Overview
<else> is a synonym for <elseif cond="true"/>.
6.2.6.2: <else> Attribute Details
| none | | | | none | |
else is a synonym for elseif cond="true".
|
6.2.7: <fetch>
6.2.7.1: Overview
<fetch> is used to asynchronously fetch content identified by the attributes of the
<fetch>. The fetched content may either be a CCXML document, or script content. Content that has
been acquired using <fetch> is accessible through other elements defined by CCXML. Execution
returns from the element immediately, and the CCXML application can continue on while the platform works to fetch
the identified resource. When the fetch request has been completed, an event is generated against the session that
initiated the fetch. The event is one of fetch.done, which indicates that the identified content was
fetched successfully, or error.fetch, indicative of a failure to fetch the requested content. Note
that even if content is successfully fetched, errors in processing fetched content (for instance, a CCXML document
with a syntax error) may result in an error.fetch being thrown.
The fetch request is local to the session that initiated the <fetch>, and is referenced
through a unique identifier generated by the CCXML platform. The application may obtain the unique identifier for a
fetch request by providing an ECMAScript left-hand-side expression in the fetchid attribute when the
fetch is performed. The fetch identifier can also be obtained as a property of the fetch.done event.
The application uses the fetch identifier in any CCXML elements that reference fetched content, currently
<goto> and <script>.
Fetched content has a lifetime that is limited to that of the document in which it is fetched. Therefore,
following a transition to a new CCXML document using <goto>, content fetched in the scope of the
current document is no longer accessible. Note that this should not be taken to preclude platform-level
optimizations or caching of resources that are fetched multiple times.
The use of <fetch> to obtain content does not compel the application to make use of that
content. However, it is wasteful of system resources to fetch resources that are not used. Platforms are
responsible for clearing out unused fetch resources, and may impose limits on the resources that can be fetched by
a single session.
6.2.7.2: <fetch> Attribute Details
| next | true | | ECMAScript Expression | none | must evaluate to a valid URL |
An ECMAScript expression which returns the URI of the resource to be fetched.
|
| type | false | | ECMAScript Expression | application/ccxml+xml |
application/ccxml+xml
text/ecmascript
text/javascript
|
An ECMAScript expression which returns a character string that specifies
the MIME type of the fetched content.
Values defined by the specification are:
- application/ccxml+xml
- This species that the document being fetched is a CCXML document.
- text/ecmascript
- This species that the fetched content is ECMA Script.
- text/javascript
- This species that the fetched content is JAVA Script.
|
| namelist | false | | Var List | none | List of ECMAScript Variable names |
A list of zero or more whitespace separated CCXML variable names.
These variables will be submitted to the server, with the same qualification
as used in the namelist.
When an ECMAscript variable is submitted to the server, its value is first
converted into a string before being submitted.
If the variable is an ECMAScript
Object, the mechanism by which it is submitted is not currently defined.
Instead of submitting ECMAScript Objects directly, the application developer
may explicitly submit the properties of an Object. e.g. "date.month date.year".
|
| method | false | | ECMAScript Expression | get |
get
post
|
An ECMAScript expression which returns a character string that indicates
the HTTP method to use.
Values defined by the specification are:
- get
- This indicates that the "GET" method will be used to fetch the URL.
- post
- This indicates that the "POST" method will be used while submitting the URL to the server.
|
| fetchid | false | | ECMAScript Left Hand Side Expression | none | ECMAScript Variable |
An ECMAScript left hand side expression evaluating to a previously defined variable.
The value of the attribute will receive an internally generated unique string
identifier to be associated with the completion event. This identifier can be tested by the fetch
completion event handler to distinguish among several outstanding fetch requests.
If this attribute is not specified, the fetch identifier can be acquired from the fetch completion event.
Every fetch request will receive a unique fetch identifier, even if the request if for the same URL.
|
| timeout | false | | ECMAScript Expression | none |
An ECMAScript expression which returns a character string in CSS2 [CSS2] format
|
The character string returned is interpreted as a time interval.
This interval begins when the fetch is executed. The fetch will fail if not completed at the end of this interval.
A failed fetch will return the error.fetch event.
|
| maxage | false | | ECMAScript Expression | none |
An ECMAScript expression which returns a valid time value for the HTTP 1.1 request [RFC2616]
|
The character string returned is interpreted as a time interval.
This indicates that the document is willing to use content whose age is no greater than the specified time
in seconds (cf. 'max-age' in HTTP 1.1 [RFC2616]). The document is not willing
to use stale content, unless maxstale is also provided.
|
| maxstale | false | | ECMAScript Expression | none |
An ECMAScript expression which returns a valid time value for the HTTP 1.1 request [RFC2616]
|
The character string returned is interpreted as a time interval.
This indicates that the document is willing to use content that has exceeded its expiration time
(cf. 'max-age' in HTTP 1.1 [RFC2616]). If maxstale is assigned a value, then
the document is willing to accept content that has exceeded its expiration time by no more than the
specified number of seconds.
|
| enctype | false |
Valid only when the value of the method is "post" | ECMAScript Expression | application/x-www-form-urlencoded |
valid media encoding type
|
An ECMAScript expression which returns a character string that indicates
the media encoding type of the submitted document (when the value of the method is "post").
Values defined by the specification are:
- application/x-www-form-urlencoded
- This indicates that the ccxml variables specified in the namelist will be url encoded.
|
6.2.8: <goto>
6.2.8.1: Overview
<fetch>, in conjunction with <goto>, is used to transfer execution to a
different CCXML document in a multi-document CCXML application. The <fetch> tells the platform
to find, load, and parse a given CCXML document. After the fetch completes, the CCXML application can then issue a
<goto> to execute the now-fetched document.
Below is a small snippet of code from the CCXML application's event handler. We execute a
<fetch> operation, and continue on to assign to a state variable, and maybe handle more events.
Eventually, the fetch completes, the CCXML platform services the event, and the application performs the
<goto>.
<fetch next="'http://www.web.com/control.ccxml'"/>
<--control continues here->
<assign name="state_var" expr="'fetch_wait'"/>
</transition>
<!-- ……… -->
<transition state="fetch_wait" event="fetch.done" name="evt"/>
<goto fetchid="evt.fetchid"/>
</transition>
A <goto> transfers control to the document obtained through a fetch request, using the
platform-generated unique identifier associated with that fetch request. The fetch completion event
MUST have arrived before the <goto> is executed, otherwise, an
error.semantic event is generated. If the fetched content referenced by the fetch identifier is not a
CCXML document, or the fetch identifier is invalid and does not correspond to any fetch request, this also results
in an error.semantic event.
When a <goto> is executed, the target document replaces the current document in its session.
Event sources associated with this session are inherited by the target document. Execution of the current document
terminates.
6.2.8.2: <goto> Attribute Details
| fetchid | true | | ECMAScript Expression | none | A valid fetch id
|
An ECMAScript expression which returns the fetch identifier of a completed fetch request
acquired either in a fetch with the fetchid attribute, or from the fetchid attribute of a
fetch.done event.
If the attribute value is invalid, an error.semantic event will be thrown.
|
6.2.8.3: <fetch> and <goto> Example
The following code shows the use of the <fetch> and <goto>
elements along with the fetchid attribute to handle more complex fetching situations:
<?xml version="1.0" encoding="UTF-8"?>
<ccxml version="1.0" xmlns="http://www.w3.org/2002/09/ccxml">
<!-- var to hold the value of the fetch
identifier that we care about -->
<var name="myGoodFetchID"/>
<eventprocessor>
<transition event="ccxml.loaded">
<!-- stick the value of the fetch
identifier in the myGoodFetchID var -->
<fetch fetchid="myGoodFetchID"
next="'http://www.example.com/goodfetch.ccxml'"/>
<!-- do not bother saving the fetch id's for these,
we would just ingore them anyway -->
<fetch next="'http://www.example.com/fakefetch1.ccxml'"/>
<fetch next="'http://www.example.com/fakefetch2.ccxml'"/>
</transition>
<transition event="fetch.done" name="evt">
<if cond="myGoodFetchID == evt.fetchid">
<!-- only matched if we have fetched
http://www.example.com/goodfetch.ccxml -->
<goto fetchid="evt.fetchid"/>
</if>
</transition>
</eventprocessor>
</ccxml>
6.2.9: <createccxml>
6.2.9.1: Overview
<createccxml> is used to create another CCXML session, which begins execution with the document
identified by this element. The term "session" is not meant to imply a particular form of implementation. A CCXML
session exists for each concurrently executing CCXML document. A session provides independent execution and a
separate variable space for the CCXML documents it executes. A session is associated with one or more event sources
and will receive events only from those endpoints. The execution of a CCXML document MAY add
or subtract event sources from a session. The new CCXML session has no relation to its creator once spawned, and has
a wholly separate lifetime and address space.
Execution returns from the <createccxml> element immediately, and the CCXML interpreter can
continue on while the new CCXML session is established and loads its initial document. If the new session is
successfully established or a failure occurs an event is generated and is delivered to the session that executed the
<createccxml> element.
6.2.9.2 <createccxml> Attribute Details
| next | true | | ECMAScript Expression | none | a valid URL |
An ECMAScript expression which returns the URI of the resource to be fetched.
|
| namelist | false | | Var List | none | List of ECMAScript Variable names |
A list of zero or more whitespace separated CCXML variable names.
These variables will be submitted to the server, with the same qualification
as used in the namelist.
When an ECMAscript variable is submitted to the server, its value is first
converted into a string before being submitted.
If the variable is an ECMAScript
Object, the mechanism by which it is submitted is not currently defined.
Instead of submitting ECMAScript Objects directly, the application developer
may explicitly submit the properties of an Object. e.g. "date.month date.year".
|
| method | false | | ECMAScript Expression | get |
get
post
|
An ECMAScript expression which returns a character string that indicates
the HTTP method to use.
Values defined by the specification are:
- get
- This indicates that the "GET" method will be used to fetch the URL.
- post
- This indicates that the "POST" method will be used while submitting the URL to the server.
|
| sessionid | false | | ECMAScript Left Hand Side Expression | none | ECMAScript Variable |
An ECMAScript left hand side expression evaluating to a previously defined variable.
The value of the attribute will receive an internally generated unique string
identifier which identifies the newly created session.
|
| timeout | false | | ECMAScript Expression | none |
An ECMAScript expression which returns a character string in CSS2 [CSS2] format
|
The character string returned is interpreted as a time interval.
This time interval is interpreted by the new CCXML session as the maximum time it should wait for the
completion of the fetch for the initial document specified by the next attribute. If the new CCXML
session is unable to fetch the initial document within the timeout interval, an
error.fetch event must be thrown.
|
| maxage | false | | ECMAScript Expression | none |
An ECMAScript expression which returns a valid time value for the HTTP 1.1 request [RFC2616]
|
The character string returned is interpreted as a time interval.
This indicates that the document is willing to use content whose age is no greater than the specified time
in seconds (cf. 'max-age' in HTTP 1.1 [RFC2616]). The document is not willing
to use stale content, unless maxstale is also provided.
|
| maxstale | false | | ECMAScript Expression | none |
An ECMAScript expression which returns a valid time value for the HTTP 1.1 request [RFC2616]
|
The character string returned is interpreted as a time interval.
This indicates that the document is willing to use content that has exceeded its expiration time
(cf. 'max-age' in HTTP 1.1 [RFC2616]). If maxstale is assigned a value, then
the document is willing to accept content that has exceeded its expiration time by no more than the
specified number of seconds.
|
| enctype | false |
Valid only when the value of the method is "post" | ECMAScript Expression | application/x-www-form-urlencoded |
valid media encoding type
|
An ECMAScript expression which returns a character string that indicates
the media encoding type of the submitted document (when the value of the method is "post").
Values defined by the specification are:
- application/x-www-form-urlencoded
- This indicates that the ccxml variables specified in the namelist will be url encoded.
|
6.2.10: <exit>
6.2.10.1: Overview
<exit> ends execution of the CCXML session. All pending events are discarded, and there is no
way to restart CCXML execution.
6.2.10.2 <exit> Attribute Details
| expr | false | | ECMAScript Expression | undefined | |
A return ECMAScript expression (e.g. 0 or 'oops!'). If this attribute is omitted,
the return value is ECMAScript undefined. This value is stored as a property of the exit event.
|
| namelist | false | | Var List | none | List of ECMAScript Variable names |
A list of one or more whitespace separated CCXML unqualified variable names to be returned.
These variable names and their associated values will be set as properties of
the exit event.
|
A CCXML document executing the <exit> will generate a ccxml.exit event to the
parent session. The exiting document will be identified on the exit event by its session ID.
6.2.11: <log>
6.2.11.1: Overview
<log> allows an application to generate a logging or debug message which a developer can use to
help in application development or post-execution analysis of application performance. The manner in which the
message is displayed or logged is platform-dependent. The usage of label is platform-dependent. The use of
<log> SHOULD have no other side-effects on interpretation.
<log>is an empty element.
6.2.11.2 <log> Attribute Details
| label | false | | ECMAScript Expression | none | |
An ECMAScript expression which returns a character string which may be
used, for example, to indicate the purpose of the log.
|
| expr | true | | ECMAScript Expression | none | |
An ECMAScript expression evaluating to a string to be logged.
|
6.3: Events
6.3.1: Overview
CCXML allows operations such as document fetching, startup and shutdown to execute independently. CCXML events
that describe these operations are defined below:
6.3.2: fetch.done - Fetch Completion Event
This event is generated when a fetch request completes. It is delivered to the document which issued the
request.
The fields of this event are:
| Field Name |
Details |
name |
fetch.done |
fetchid |
The internally generated unique fetch identifier |
uri |
The URI of the fetch request. |
6.3.3: error.fetch - Fetch Error Event
This event is generated when a fetch request does not successfully complete. It is delivered to the document which
issued the request.
The fields of this event are:
| Field Name |
Details |
name |
error.fetch |
fetchid |
The internally generated unique fetch identifier |
reason |
A string description of the fetch error. |
uri |
The URI of the fetch request. |
6.3.4: ccxml.exit - CCXML Document Exit Event
This event is generated when a CCXML document
executes an <exit>.
This event is only generated when the session executing the
<exit/> has a parent session. This event is sent to the
parent session and not the session executing the <exit/>.
The fields of this event are:
| Field Name |
Details |
name |
ccxml.exit |
sessionid |
the identifier of the exiting session; this is the same value returned to the
sessionid attribute of the <createccxml> which created this session; |
expr |
the value of the <exit> expr attribute; |
namelist |
If the namelist attribute was specified in the
<exit>, this property is a string valued array of the names in the list. The length of the
property is equal to the number of names in the list. The actual values are stored in the " values "
sub-object. |
values.* |
Each name in the namelist is a property whose value is the value of the name at
the time the <exit> was executed. |
6.3.5: ccxml.loaded - CCXML Document Loaded Event
This event is thrown once the document is parsed and ready for execution (document initialization occurs between
the fetched and loaded events). The CCXML platform SHOULD generate this event when the CCXML
document is first loaded, both at session startup and after transferring control to a new document with the
<goto>. This event would be processed after the platform had executed the document initialization
including executing any elements under the <ccxml> .
The fields of this event are:
| Field Name |
Details |
name |
ccxml.loaded |
sessionid |
the identifier of the session on which this document is executing; |
parent |
the identifier of the session which issued the <createccxml>
to start this document; if this document was started directly by the CCXML platform, the identifier is 0 |
6.3.6: ccxml.kill - CCXML kill Event
The kill event can be used by the platform to terminate a session without an
explicit <exit>. There are two versions of this event: catchable, and non-catchable.
The ccxml.kill event can be caught, typically to perform a clean-up operation at the
end of a session. If the event is caught the session will not be terminated unless the an <exit>
element is processed. If the event is not caught the session will be terminated and all active connections,
conferences and dialogs that are owned by that session will be automatically terminated by the platform.
Unlike other events, the ccxml.kill.unconditional event is the only event that
cannot be caught by an application; it will unconditionally terminate the session and all active connections,
conferences and dialogs that are owned by that session will be automatically terminated by the platform.
Note that while the normal cause of a ccxml.kill or
ccxml.kill.unconditional event being queued to a session is that the platform wishes to terminate the
session, it is legal for any event I/O processor to generate a ccxml.kill or
ccxml.kill.unconditional event. For instance, it is legal for one CCXML session to unconditionally kill
another session by sending a ccxml.kill.unconditional event using <send>. Note,
however, that platforms may impose rules that prevent one session from arbitrarily killing another (to prevent
malicious applications, for instance).
The fields of this event are:
| Field Name |
Details |
name |
ccxml.kill |
sessionid |
the identifier of the session |
reason |
a string describing the reason the platform sent the kill event. Content of this
field is platform-specific, and is only for informative purposes. |
6.3.7: ccxml.created - CCXML Session Create Completion Event
This event is generated when a <createccxml> request completes successfully. It is delivered to
the document which issued the request and indicates that the new session has retrieved the specified initial CCXML
document and has begun execution of it.
The fields of this event are:
| Field Name |
Details |
name |
ccxml.created |
sessionid |
The identifier of the newly created CCXML session. This is the same identifier as
was returned on the sessionid attribute of the <createccxml> request that created
the session. |
6.3.8: error.createccxml - CCXML Session Create Failed Event
This event is generated when a <createccxml> request fails to complete. It is delivered to the
document which issued the request and indicates that the new session has not been created.
The fields of this event are:
| Field Name |
Details |
name |
error.createccxml |
sessionid |
The identifier of the failing CCXML session. This is the same identifier as was
returned on the sessionid attribute of the <createccxml> request that created the
session. |
reason |
A string description of the error encountered. |
6.3.9: error.unsupported - CCXML Unsupported Operation
This event is generated when an OPTIONAL operation that is not supported by the platform is executed.
The fields of this event are:
| Field Name |
Details |
name |
error.unsupported |
reason |
A string description of the error encountered. |
7: Dialogs
7.1: Overview
CCXML does not provide any mechanism for interacting with callers but relies on separate dialog environments such
as VoiceXML [ VOICEXML ]. Whenever interaction with a caller is required a
CCXML session can initiate a separate dialog provided by a VoiceXML capability or some other technology. When the
interaction is complete, control returns to the CCXML session which can use any results returned by the dialog
environment to decide what should happen next.
Dialogs initiated by CCXML sessions are not tied to any single dialog language or technology.
Any dialog system which fulfils CCXML's requirements MAY be used for
interaction with the caller. Examples of dialog systems include VoiceXML, SALT [
SALT ], traditional IVR,
3GPP MRF as well as simple media handling systems for fax, media
playback and recording, DTMF detection, answer-machine detectors, etc. A CCXML platform MAY support
interaction with several dialog systems with the selection of the particular technology being based on the MIME type
specified when the dialog is initiated.
All CCXML elements that manipulate dialogs are asynchronous with control returning immediately to the CCXML
session after the operation is initiated. The CCXML session is notified when the dialog operation successfully
completes, or fails, by an asynchronous event.
A CCXML program initiates a dialog using the <dialogstart> element. Execution of this element
connects a dialog environment to a connection and instructs it to start interacting with the caller. For some dialog
environments it may take some time to initialize the dialog environment and thus the use of the
<dialogstart> element alone may cause the caller to hear silence, or "dead air". To avoid this
situation CCXML provides an ability to ready a dialog environment prior to connecting and starting it, this is done
using the <dialogprepare> element. Any dialog that has been either started with
<dialogstart>, or prepared with <dialogprepare> can be terminated using the
<dialogterminate> element. CCXML implementations MUST support the
<dialogprepare>, <dialogstart>, and <dialogterminate>
elements though the exact behaviour may vary depending on the dialog environments supported.
The following examples illustrate the valid use patterns for these three elements. Firstly the normal case of
preparing a dialog, starting it, then optionally terminating it before normal completion. This example illustrates
the use of <dialogprepare> to ready a dialog while the call is left in alerting state. When the
alerting notification arrives the script executes a <dialogprepare> to prepare a dialog and
associate it with the connection. When the dialog is prepared the script executes an <accept> to
connect the call and then when the connection transitions to connected state, a <dialogstart>
element is used to execute the previously prepared dialog.
<transition event="connection.alerting" name="evt">
<dialogprepare src="..." connectionid="evt.connectionid"/>
</transition>
<transition event="dialog.prepared" name="evt">
<accept connectionid="session.dialogs[evt.dialogid].connectionid"/>
</transition>
<transition event="connection.connected" name="evt">
<dialogstart prepareddialogid="evt.dialogid"
connectionid="evt.connectionid"/>
</transition>
(optionally)
<transition event="???">
<dialogterminate dialogid="..." />
</transition>
The next example shows a single step dialog invocation without dialog preparation. In this case a connection in
alerting state is accepted and, when the transition to connected state occurs, a <dialogstart>
element is used to start the dialog.
<transition event="connection.alerting" name="evt">
<accept connectionid="evt.connectionid"/>
</transition>
<transition event="connection.connected" name="evt">
<dialogstart src="..." connectionid="evt.connectionid"/>
</transition>
(optionally)
<transition event="???">
<dialogterminate dialogid="..." />
</transition>
The final example shows the case where a dialog which has been previously prepared is cancelled before a
<dialogstart> has been issued. A dialog may be terminated when it is in the prepared state or
while it is being prepared such as might be the case if the caller hangs up at some arbitrary point. In this case the
<dialogterminate> may be executed before or after the dialog.prepared event is
processed.
<transition event="connection.connected"> name="evt">
<dialogprepare src="..." connectionid="evt.connectionid"/>
</transition>
<transition event="connection.disconnected" name="evt">
<dialogterminate dialogid="evt.connection.dialogid" />
</transition>
7.2: Elements
7.2.1: <dialogprepare>
7.2.1.1: Overview
<dialogprepare> is used to get an appropriate dialog handler ready to process, it is used as
the precursor to a <dialogstart> request. The element includes a URI reference to the initial
document for the dialog. The new dialog is prepared on a separate logical execution thread (this
MAY be a thread, process, or system depending upon platform implementation) and does not
block the processing of further events by the CCXML session. The use of the <dialogprepare>
element is entirely optional, applications may choose to simply use <dialogstart> without prior
preparation.
Optionally the new dialog may be associated with a connection by specifying the connectionid
attribute.
When preparation of the dialog competes successfully a dialog.prepared event is posted to the event
queue of the CCXML session. If however the dialog cannot be prepared for any reason, an
error.dialog.notprepared event is posted.
CCXML implementations MUST support dialog preparation though the processing carried out
as part of a <dialogprepare> request is dialog manager specific. In the case of a dialog manager
that does not support preparation, the CCXML implementation MUST as a minimum, note the
values provided via the src, namelist, and connectionid attributes, create a
Dialog object, and return a new unique value to the location defined by the dialogid attribute.
The CCXML session selects what it believes to be the appropriate dialog manager based on the MIME type specified
by the type attribute without retrieving the resource specified by the src URI. If, when
the dialog manager retrieves the content, it finds the MIME type, as specified by the
HTTP headers, differs from that specifed by the
type attribute, it SHOULD raise an error.dialog.notprepared event
with a reason indicating the type mismatch. The dialog manager MUST NOT ignore
the type mismatch or render the resource as a different type based on the
HTTP headers or on inspection of the document data. Refer to
the W3C guidelines for client handling of MIME types [MIME-TAG] for
further information.
7.2.1.2: <dialogprepare> Attribute Details
| src | true | | ECMAScript Expression | none | a Dialog URL |
An ECMAScript expression which returns a character string identifying the URI
of the dialog document that the dialog interpreter should prepare.
|
| type | false | | ECMAScript Expression | application/voicexml+xml |
a Valid MIME Type
|
An ECMAScript expression which returns a character string that specifies
the MIME type of the document, and as a result determines which dialog manager
environment is actually used.
Values defined by the specification are:
- application/voicexml+xml
- This MIME type would request a VoiceXML interpreter instance.
- audio/wav
- This MIME type would request a dialog manager that merely plays wave files.
|
| namelist | false | | Var List | none | List of ECMAScript Variable names |
A list of one or more whitespace separated CCXML variable names.
These variables will be submitted to the server, with the same qualification
as used in the namelist.
When an ECMAscript variable is submitted to the server, its value is first
converted into a string before being submitted.
If the variable is an ECMAScript
Object, the mechanism by which it is submitted is not currently defined.
Instead of submitting ECMAScript Objects directly, the application developer
may explicitly submit the properties of an Object. e.g. "date.month date.year".
|
| dialogid | false | | ECMAScript Left Hand Side Expression | none | ECMAScript Variable |
An ECMAScript left hand side expression evaluating to a previously defined variable.
The value of the attribute will receive a dialog identifier value for
the launched dialog interpreter instance. This identifier may be used on future invocations
of dialogstart, dialogterminate, join, or unjoin.
|
| connectionid | false | Can not be used with conferenceid | ECMAScript Expression | none |
Connection IDs
|
An Optional ECMAScript expression which returns the identifier of a connection.
The specified connection will be associated with the dialog being prepared.
If the attribute value is invalid, an error.semantic event will be thrown.
|
| conferenceid | false | Can not be used with connectionid | ECMAScript Expression | none |
Conference IDs
|
An Optional ECMAScript expression which returns the identifier of`a confe2ence bridge.
A connection will be allocated for the dialog being prepared.
If the attribute value is invalid, an error.semantic event will be thrown.
|
| mediadirection | false | | ECMAScript Expression | both |
both
dialogtransmit
dialogreceive
|
An ECMAScript expression that defines the direction of the
media flow between the Dialog and the Connection or Conference
specified by the connectionid or conferenceid attribute.
The following values can be used:
- both
- Specifies a full duplex connection
where the media flows in both directions.
- dialogtransmit
- The dialog transmits media to
the Connection or Conference but does
not receive any media streams.
- dialogreceive
- The dialog receives media from
the Connection or Conference but does
not transmit any media streams.
The bridge does not take place until a subsequent dialogstart
is executed, but this attribute can be provided as guidance to the dialog
environment for preparation. If no value is specified, the dialog environment
should make no assumptions as to the bridging type.
For more information about connections and bridges,
refer to Section 10 .
|
| maxage | false | | ECMAScript Expression | none |
An ECMAScript expression which returns a valid time value for the HTTP 1.1 request [RFC2616]
|
The character string returned is interpreted as a time interval.
This indicates that the document is willing to use content whose age is no greater than the specified time
in seconds (cf. 'max-age' in HTTP 1.1 [RFC2616]). The document is not willing
to use stale content, unless maxstale is also provided.
|
| maxstale | false | | ECMAScript Expression | none |
An ECMAScript expression which returns a valid time value for the HTTP 1.1 request [RFC2616]
|
The character string returned is interpreted as a time interval.
|