You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
4311 lines
169 KiB
4311 lines
169 KiB
<?xml version="1.0" encoding="UTF-8"?>
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
|
|
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
|
<html xmlns="http://www.w3.org/1999/xhtml" lang="EN">
|
|
<head>
|
|
<meta name="generator" content="HTML Tidy, see www.w3.org" />
|
|
<title>Multimodal Architecture and Interfaces</title>
|
|
<style type="text/css">
|
|
code { font-family: monospace; }
|
|
|
|
div.constraint,
|
|
div.issue,
|
|
div.note,
|
|
div.notice { margin-left: 2em; }
|
|
|
|
ol.enumar { list-style-type: decimal; }
|
|
ol.enumla { list-style-type: lower-alpha; }
|
|
ol.enumlr { list-style-type: lower-roman; }
|
|
ol.enumua { list-style-type: upper-alpha; }
|
|
ol.enumur { list-style-type: upper-roman; }
|
|
|
|
|
|
div.exampleInner pre { margin-left: 1em;
|
|
margin-top: 0em; margin-bottom: 0em}
|
|
div.exampleOuter {border: 4px double gray;
|
|
margin: 0em; padding: 0em}
|
|
div.exampleInner { background-color: #d5dee3;
|
|
border-top-width: 4px;
|
|
border-top-style: double;
|
|
border-top-color: #d3d3d3;
|
|
border-bottom-width: 4px;
|
|
border-bottom-style: double;
|
|
border-bottom-color: #d3d3d3;
|
|
padding: 4px; margin: 0em }
|
|
div.exampleWrapper { margin: 4px }
|
|
div.exampleHeader { font-weight: bold;
|
|
margin: 4px}
|
|
|
|
table {
|
|
width:80%;
|
|
border:1px solid #000;
|
|
border-collapse:collapse;
|
|
font-size:90%;
|
|
}
|
|
|
|
td,th{
|
|
border:1px solid #000;
|
|
border-collapse:collapse;
|
|
padding:5px;
|
|
}
|
|
|
|
|
|
caption{
|
|
background:#ccc;
|
|
font-size:140%;
|
|
border:1px solid #000;
|
|
border-bottom:none;
|
|
padding:5px;
|
|
text-align:center;
|
|
}
|
|
|
|
img.center {
|
|
display: block;
|
|
margin-left: auto;
|
|
margin-right: auto;
|
|
}
|
|
p.caption {
|
|
text-align: center
|
|
}
|
|
|
|
|
|
.RFC2119 {
|
|
text-transform: lowercase;
|
|
font-style: italic;
|
|
}
|
|
</style>
|
|
|
|
<link rel="stylesheet" type="text/css"
|
|
href="http://www.w3.org/StyleSheets/TR/W3C-CR.css" />
|
|
</head>
|
|
<body>
|
|
<div class="head">
|
|
<p><a href="http://www.w3.org/"><img
|
|
src="http://www.w3.org/Icons/w3c_home" alt="W3C" height="48"
|
|
width="72" /></a></p>
|
|
|
|
<h1><a name="title" id="title" />Multimodal Architecture and
|
|
Interfaces</h1>
|
|
|
|
<h2><a name="w3c-doctype" id="w3c-doctype" />W3C Candidate
|
|
Recommendation <i>12</i> <i>January</i> <i>2012</i></h2>
|
|
|
|
<dl>
|
|
<dt>This version:</dt>
|
|
|
|
<dd><a
|
|
href="http://www.w3.org/TR/2012/CR-mmi-arch-20120112/">http://www.w3.org/TR/2012/CR-mmi-arch-20120112/</a></dd>
|
|
|
|
<dt>Latest version:</dt>
|
|
|
|
<dd><a
|
|
href="http://www.w3.org/TR/mmi-arch/">http://www.w3.org/TR/mmi-arch/</a></dd>
|
|
|
|
<dt>Previous version:</dt>
|
|
|
|
<dd><a
|
|
href="http://www.w3.org/TR/2011/WD-mmi-arch-20110906/">http://www.w3.org/TR/2011/WD-mmi-arch-20110906/</a></dd>
|
|
|
|
<dt>Editor:</dt>
|
|
|
|
<dd>Jim Barnett, Genesys Telecommunications Laboratories</dd>
|
|
|
|
<dt>Authors:</dt>
|
|
|
|
<dd>Michael Bodell, Microsoft</dd>
|
|
|
|
<dd>Deborah Dahl, Invited Expert</dd>
|
|
|
|
<dd>Ingmar Kliche, Deutsche Telekom AG</dd>
|
|
|
|
<dd>Jim Larson, Invited Expert</dd>
|
|
|
|
<dd>Raj Tumuluri, Openstream</dd>
|
|
|
|
<dd>Moshe Yudkowsky, Invited Expert</dd>
|
|
|
|
<dd>Muthuselvam Selvaraj, (until 2009, while at HP)</dd>
|
|
|
|
<dd>Brad Porter (until 2005, while at Tellme)</dd>
|
|
|
|
<dd>Dave Raggett (until 2007, while at W3C/Volantis)</dd>
|
|
|
|
<dd>T.V. Raman (until 2005, while at IBM)</dd>
|
|
|
|
<dd>Andrew Wahbe (until 2006, while at VoiceGenie)</dd>
|
|
</dl>
|
|
|
|
<p class="copyright"><a
|
|
href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a>
|
|
© 2012 <a href="http://www.w3.org/"><acronym
|
|
title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup> (<a
|
|
href="http://www.csail.mit.edu/"><acronym
|
|
title="Massachusetts Institute of Technology">MIT</acronym></a>, <a
|
|
href="http://www.ercim.eu/"><acronym
|
|
title="European Research Consortium for Informatics and Mathematics">
|
|
ERCIM</acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>),
|
|
All Rights Reserved. W3C <a
|
|
href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">
|
|
liability</a>, <a
|
|
href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">
|
|
trademark</a> and <a
|
|
href="http://www.w3.org/Consortium/Legal/copyright-documents">document
|
|
use</a> rules apply.</p>
|
|
</div>
|
|
|
|
<hr />
|
|
<div>
|
|
<h2><a name="abstract" id="abstract" />Abstract</h2>
|
|
|
|
<p>This document describes a loosely coupled architecture for
|
|
multimodal user interfaces, which allows for co-resident and
|
|
distributed implementations, and focuses on the role of markup and
|
|
scripting, and the use of well defined interfaces between its
|
|
constituents.</p>
|
|
</div>
|
|
|
|
<div>
|
|
<h2><a name="status" id="status" />Status of this Document</h2>
|
|
|
|
<p>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 <a
|
|
href="http://www.w3.org/TR/">W3C technical reports index</a> at
|
|
http://www.w3.org/TR/.</p>
|
|
|
|
<p>This is the 12 January 2012 W3C Candidate Recommendation of
|
|
"Multimodal Architecture and Interfaces". W3C publishes a technical
|
|
report as a Candidate Recommendation to indicate that the document
|
|
is believed to be stable, and to encourage implementation by the
|
|
developer community.</p>
|
|
|
|
<p>This document has been produced as part of the W3C <a
|
|
href="http://www.w3.org/2002/mmi/Activity.html">Multimodal
|
|
Interaction Activity</a>, following the procedures set out for the
|
|
<a href="http://www.w3.org/Consortium/Process/">W3C Process</a>.
|
|
The authors of this document are members of the <a
|
|
href="http://www.w3.org/2002/mmi/">Multimodal Interaction Working
|
|
Group</a>.</p>
|
|
|
|
<p>This document was produced by a group operating under the <a
|
|
href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5
|
|
February 2004 W3C Patent Policy</a>. W3C maintains a <a
|
|
href="http://www.w3.org/2004/01/pp-impl/34607/status"
|
|
rel="disclosure">public list of any patent disclosures</a> 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 <a
|
|
href="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">
|
|
Essential Claim(s)</a> must disclose the information in accordance
|
|
with <a
|
|
href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">
|
|
section 6 of the W3C Patent Policy</a>.</p>
|
|
|
|
<p>Publication as a Candidate Recommendation 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.</p>
|
|
|
|
<p>There is no normative change since the <a
|
|
href="http://www.w3.org/TR/2011/WD-mmi-arch-20110906/">second Last
|
|
Call Working Draft</a> in September 2011, though several
|
|
clarifications had been added to the <a
|
|
href="http://www.w3.org/TR/2011/WD-mmi-arch-20110906/">second Last
|
|
Call Working Draft</a> in order to address detailed feedback from
|
|
the Multimodal public list. Please check the <a
|
|
href="mmi-arch-disp.html">Disposition of Comments</a> received
|
|
during the first Last Call period. A <a
|
|
href="diff.html">diff-marked version</a> of this document is also
|
|
available for comparison purposes.</p>
|
|
|
|
<p>The entrance criteria to the Proposed Recommendation phase
|
|
require at least two independently developed interoperable
|
|
implementations of each feature. Detailed implementation
|
|
requirements and the invitation for participation in the
|
|
Implementation Report are provided in the <a
|
|
href="http://www.w3.org/2002/mmi/2012/mmi-arch-irp/Overview.html">Implementation
|
|
Report Plan</a>. We expect to meet all requirements of that report
|
|
within the Candidate Recommendation period closing <em>29 February
|
|
2012</em>. The Multimodal Interaction Working Group will advance
|
|
Multimodal Architecture and Interfaces to Proposed Recommendation
|
|
no sooner than <em>29 February 2012.</em></p>
|
|
|
|
<p>The following features in the current draft specification are
|
|
considered to be at risk of removal due to potential lack of
|
|
implementations:</p>
|
|
|
|
<ul>
|
|
<li>The Confidential field in all life-cycle events.</li>
|
|
|
|
<li>The RequestAutomaticUpdate field of the StatusRequest
|
|
message.</li>
|
|
|
|
<li>The AutomaticUpdate field of the StatusResponse message.</li>
|
|
</ul>
|
|
|
|
<p>Comments for this specification are welcomed until 29 February
|
|
2012 and should have a subject starting with the prefix '[ARCH]'.
|
|
Please send them to <<a
|
|
href="mailto:www-multimodal@w3.org">www-multimodal@w3.org</a>>,
|
|
the public email list for issues related to Multimodal. This list
|
|
is <a
|
|
href="http://lists.w3.org/Archives/Public/www-multimodal/">archived</a>
|
|
and acceptance of this archiving policy is requested automatically
|
|
upon first post. To subscribe to this list send an email to <<a
|
|
href="mailto:www-multimodal-request@w3.org">www-multimodal-request@w3.org</a>>
|
|
with the word subscribe in the subject line.</p>
|
|
|
|
<p>For more information about the Multimodal Interaction Activity,
|
|
please see the <a
|
|
href="http://www.w3.org/2002/mmi/Activity">Multimodal Interaction
|
|
Activity statement</a>.</p>
|
|
</div>
|
|
|
|
<div class="toc">
|
|
<h2><a name="contents" id="contents" />Table of Contents</h2>
|
|
|
|
<p class="toc">1 <a href="#terminology">Conformance
|
|
Requirements</a><br />
|
|
2 <a href="#d3e274">Summary</a><br />
|
|
3 <a href="#overview">Overview</a><br />
|
|
4 <a href="#Design">Design versus Run-Time considerations</a><br />
|
|
4.1 <a href="#d3e327">Markup and The
|
|
Design-Time View</a><br />
|
|
4.2 <a href="#Runtime">Software
|
|
Constituents and The Run-Time View</a><br />
|
|
4.3 <a
|
|
href="#Relationship_to_EMMA">Relationship to EMMA</a><br />
|
|
5 <a href="#OverviewConstituents">Overview of
|
|
Architecture</a><br />
|
|
5.1 <a href="#ArchDiagram">Run-Time
|
|
Architecture Diagram</a><br />
|
|
5.2 <a href="#Constitents">The
|
|
Constituents</a><br />
|
|
5.2.1 <a
|
|
href="#d3e395">The Interaction Manager</a><br />
|
|
5.2.2 <a
|
|
href="#d3e423">The Data Component</a><br />
|
|
5.2.3 <a
|
|
href="#ModalityComponents">The Modality Components</a><br />
|
|
5.2.4 <a
|
|
href="#d3e443">The Runtime Framework</a><br />
|
|
5.2.4.1
|
|
<a href="#d3e448">The Event Transport Layer</a><br />
|
|
5.2.4.1.1
|
|
<a href="#security">Event and Information Security</a><br />
|
|
5.2.5 <a
|
|
href="#d3e502">System and OS Security</a><br />
|
|
5.2.6 <a
|
|
href="#d3e509">Media stream handling</a><br />
|
|
5.2.7 <a
|
|
href="#ConstituentExamples">Examples</a><br />
|
|
6 <a href="#Interfaces">Interface between the Interaction Manager
|
|
and the Modality Components</a><br />
|
|
6.1 <a href="#ComponentInterface">Common
|
|
Event Fields</a><br />
|
|
6.1.1 <a
|
|
href="#ContextField">Context</a><br />
|
|
6.1.2 <a
|
|
href="#SourceField">Source</a><br />
|
|
6.1.3 <a
|
|
href="#TargetField">Target</a><br />
|
|
6.1.4 <a
|
|
href="#RequestIDField">RequestID</a><br />
|
|
6.1.5 <a
|
|
href="#StatusField">Status</a><br />
|
|
6.1.6 <a
|
|
href="#StatusInfoField">StatusInfo</a><br />
|
|
6.1.7 <a
|
|
href="#DataField">Data</a><br />
|
|
6.1.8 <a
|
|
href="#ConfidentialField">Confidential</a><br />
|
|
6.2 <a href="#LifeCycleEvents">Standard
|
|
Life Cycle Events</a><br />
|
|
6.2.1 <a
|
|
href="#d3e666">NewContextRequest/NewContextResponse</a><br />
|
|
6.2.1.1
|
|
<a href="#d3e683">NewContextRequest Properties</a><br />
|
|
6.2.1.2
|
|
<a href="#d3e717">NewContextResponse Properties</a><br />
|
|
6.2.2 <a
|
|
href="#d3e781">PrepareRequest/PrepareResponse</a><br />
|
|
6.2.2.1
|
|
<a href="#d3e806">PrepareRequest Properties</a><br />
|
|
6.2.2.2
|
|
<a href="#d3e880">PrepareResponse Properties</a><br />
|
|
6.2.3 <a
|
|
href="#StartRequest">StartRequest/StartResponse</a><br />
|
|
6.2.3.1
|
|
<a href="#d3e960">StartRequest Properties</a><br />
|
|
6.2.3.2
|
|
<a href="#d3e1031">StartResponse Properties</a><br />
|
|
6.2.4 <a
|
|
href="#d3e1089">DoneNotification</a><br />
|
|
6.2.4.1
|
|
<a href="#d3e1097">DoneNotification Properties</a><br />
|
|
6.2.5 <a
|
|
href="#d3e1157">CancelRequest/CancelResponse</a><br />
|
|
6.2.5.1
|
|
<a href="#d3e1171">CancelRequest Properties</a><br />
|
|
6.2.5.2
|
|
<a href="#d3e1214">CancelResponse Properties</a><br />
|
|
6.2.6 <a
|
|
href="#d3e1272">PauseRequest/PauseResponse</a><br />
|
|
6.2.6.1
|
|
<a href="#d3e1283">PauseRequest Properties</a><br />
|
|
6.2.6.2
|
|
<a href="#d3e1326">PauseResponse Properties</a><br />
|
|
6.2.7 <a
|
|
href="#d3e1384">ResumeRequest/ResumeResponse</a><br />
|
|
6.2.7.1
|
|
<a href="#d3e1407">ResumeRequest Properties</a><br />
|
|
6.2.7.2
|
|
<a href="#d3e1450">ResumeResponse Properties</a><br />
|
|
6.2.8 <a
|
|
href="#d3e1508">ExtensionNotification</a><br />
|
|
6.2.8.1
|
|
<a href="#d3e1519">ExtensionNotification Properties</a><br />
|
|
6.2.9 <a
|
|
href="#d3e1566">ClearContextRequest/ClearContextResponse</a><br />
|
|
6.2.9.1
|
|
<a href="#d3e1580">ClearContextRequest Properties</a><br />
|
|
6.2.9.2
|
|
<a href="#d3e1623">ClearContextResponse Properties</a><br />
|
|
6.2.10 <a
|
|
href="#d3e1681">StatusRequest/StatusResponse</a><br />
|
|
6.2.10.1
|
|
<a href="#d3e1692">Status Request Properties</a><br />
|
|
6.2.10.2
|
|
<a href="#d3e1748">StatusResponse Properties</a><br />
|
|
</p>
|
|
|
|
<h3><a name="appendices" id="appendices" />Appendices</h3>
|
|
|
|
<p class="toc">A <a href="#d3e1824">Modality Component
|
|
States</a><br />
|
|
B <a href="#EventExamples">Examples of Life-Cycle Events</a><br />
|
|
B.1 <a href="#d3e1945">NewContextRequest
|
|
(from MC to IM)</a><br />
|
|
B.2 <a href="#d3e1950">NewContextResponse
|
|
(from IM to MC)</a><br />
|
|
B.3 <a href="#d3e1955">PrepareRequest (from
|
|
IM to MC, with external markup)</a><br />
|
|
B.4 <a href="#d3e1960">PrepareRequest (from
|
|
IM to MC, inline VoiceXML markup)</a><br />
|
|
B.5 <a href="#d3e1965">PrepareResponse
|
|
(from MC to IM, Success)</a><br />
|
|
B.6 <a href="#d3e1970">PrepareResponse
|
|
(from MC to IM, Failure)</a><br />
|
|
B.7 <a href="#d3e1975">StartRequest (from
|
|
IM to MC)</a><br />
|
|
B.8 <a href="#d3e1980">StartResponse (from
|
|
MC to IM)</a><br />
|
|
B.9 <a href="#d3e1985">DoneNotification
|
|
(from MC to IM, with EMMA result)</a><br />
|
|
B.10 <a href="#d3e1992">DoneNotification
|
|
(from MC to IM, with EMMA "no-input" result)</a><br />
|
|
B.11 <a href="#d3e1997">CancelRequest (from
|
|
IM to MC)</a><br />
|
|
B.12 <a href="#d3e2002">CancelResponse
|
|
(from MC to IM)</a><br />
|
|
B.13 <a href="#d3e2007">PauseRequest (from
|
|
IM to MC)</a><br />
|
|
B.14 <a href="#d3e2012">PauseResponse (from
|
|
MC to IM)</a><br />
|
|
B.15 <a href="#d3e2017">ResumeRequest (from
|
|
IM to MC)</a><br />
|
|
B.16 <a href="#d3e2022">ResumeResponse
|
|
(from MC to IM)</a><br />
|
|
B.17 <a
|
|
href="#d3e2027">ExtensionNotification (formerly the data event,
|
|
sent in both directions)</a><br />
|
|
B.18 <a href="#d3e2032">ClearContextRequest
|
|
(from the IM to MC)</a><br />
|
|
B.19 <a
|
|
href="#d3e2037">ClearContextResponse (from the MC to IM)</a><br />
|
|
B.20 <a href="#d3e2042">StatusRequest (from
|
|
the IM to the MC)</a><br />
|
|
B.21 <a href="#d3e2047">StatusResponse
|
|
(from the MC to the IM)</a><br />
|
|
C <a href="#Schema">Event Schemas</a><br />
|
|
C.1 <a href="#d3e2057">mmi.xsd</a><br />
|
|
C.2 <a
|
|
href="#d3e2062">mmi-datatypes.xsd</a><br />
|
|
C.3 <a
|
|
href="#d3e2067">mmi-attribs.xsd</a><br />
|
|
C.4 <a
|
|
href="#d3e2072">mmi-elements.xsd</a><br />
|
|
C.5 <a
|
|
href="#d3e2077">NewContextRequest.xsd</a><br />
|
|
C.6 <a
|
|
href="#d3e2082">NewContextResponse.xsd</a><br />
|
|
C.7 <a
|
|
href="#d3e2087">PrepareRequest.xsd</a><br />
|
|
C.8 <a
|
|
href="#d3e2092">PrepareResponse.xsd</a><br />
|
|
C.9 <a
|
|
href="#d3e2097">StartRequest.xsd</a><br />
|
|
C.10 <a
|
|
href="#d3e2102">StartResponse.xsd</a><br />
|
|
C.11 <a
|
|
href="#d3e2107">DoneNotification.xsd</a><br />
|
|
C.12 <a
|
|
href="#d3e2112">CancelRequest.xsd</a><br />
|
|
C.13 <a
|
|
href="#d3e2117">CancelResponse.xsd</a><br />
|
|
C.14 <a
|
|
href="#d3e2122">PauseRequest.xsd</a><br />
|
|
C.15 <a
|
|
href="#d3e2127">PauseResponse.xsd</a><br />
|
|
C.16 <a
|
|
href="#d3e2132">ResumeRequest.xsd</a><br />
|
|
C.17 <a
|
|
href="#d3e2137">ResumeResponse.xsd</a><br />
|
|
C.18 <a
|
|
href="#d3e2142">ExtensionNotification.xsd</a><br />
|
|
C.19 <a
|
|
href="#d3e2147">ClearContextRequest.xsd</a><br />
|
|
C.20 <a
|
|
href="#d3e2152">ClearContextResponse.xsd</a><br />
|
|
C.21 <a
|
|
href="#d3e2157">StatusRequest.xsd</a><br />
|
|
C.22 <a
|
|
href="#d3e2162">StatusResponse.xsd</a><br />
|
|
D <a href="#LadderDiagrams">Ladder Diagrams for the MMI
|
|
Architecture with a Web Browser and VXML Interpreter</a><br />
|
|
D.1 <a href="#d3e2171">Creating a
|
|
Session</a><br />
|
|
D.2 <a href="#d3e2187">Processing User
|
|
Input</a><br />
|
|
D.3 <a href="#d3e2195">Ending a
|
|
Session</a><br />
|
|
E <a href="#LocalizationCustomization">Localization and
|
|
Customization</a><br />
|
|
F <a href="#HTTPTransport">HTTP transport of MMI lifecycle
|
|
events</a><br />
|
|
F.1 <a href="#d3e2240">Lifecycle event
|
|
transport from modality components to Interaction Manager</a><br />
|
|
F.2 <a href="#d3e2332">Lifecycle event
|
|
transport from IM to modality components (HTTP clients
|
|
only)</a><br />
|
|
F.3 <a href="#d3e2419">Lifecycle event
|
|
transport from Interaction Manager to modality components (HTTP
|
|
servers)</a><br />
|
|
F.4 <a href="#d3e2435">Error
|
|
handling</a><br />
|
|
G <a href="#glossary">Glossary</a><br />
|
|
H <a href="#creating_MC">Types of Modality Components</a><br />
|
|
H.1 <a
|
|
href="#Simple_modality_components">Simple modality
|
|
components</a><br />
|
|
H.2 <a
|
|
href="#Complex_modality_components">Complex modality
|
|
components</a><br />
|
|
H.3 <a
|
|
href="#Nested_modality_components">Nested modality
|
|
components</a><br />
|
|
I <a href="#references">Normative References</a><br />
|
|
J <a href="#d3e2590">Informative References</a><br />
|
|
</p>
|
|
</div>
|
|
|
|
<hr />
|
|
<div class="body">
|
|
<div class="div1">
|
|
<h2><a name="terminology" id="terminology" />1 Conformance
|
|
Requirements</h2>
|
|
|
|
<p>An implementation is conformant with the MMI Architecture if it
|
|
consists of one or more software constituents that are conformant
|
|
with the MMI Life-Cycle Event specification.</p>
|
|
|
|
<p>A constituent is conformant with the MMI Life-Cycle Event
|
|
specification if it supports the Life-Cycle Event interface between
|
|
the Interaction Manager and the Modality Component defined in <a
|
|
href="#Interfaces"><b>6 Interface between the Interaction Manager
|
|
and the Modality Components</b></a>. To support the Life-Cycle
|
|
Event interface, a constituent must be able to handle all
|
|
Life-Cycle events defined in <a href="#LifeCycleEvents"><b>6.2
|
|
Standard Life Cycle Events</b></a> either as an Interaction Manager
|
|
or as a Modality Component or as both.</p>
|
|
|
|
<p>Transport and format of Life-Cycle Event messages may be
|
|
implemented in any manner, as long as their contents conform to the
|
|
standard Life-Cycle Event definitions given in <a
|
|
href="#LifeCycleEvents"><b>6.2 Standard Life Cycle Events</b></a>.
|
|
Any implementation that uses XML format to represent the life-cycle
|
|
events must comply with the normative MMI XML schemas contained in
|
|
<a href="#Schema"><b>C Event Schemas</b></a>.</p>
|
|
|
|
<p>The key words <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em>, <em title="MUST NOT in RFC2119 context"
|
|
class="RFC2119">MUST NOT</em>, <em
|
|
title="REQUIRED in RFC2119 context" class="RFC2119">REQUIRED</em>,
|
|
<em title="SHALL in RFC2119 context" class="RFC2119">SHALL</em>,
|
|
<em title="SHALL NOT in RFC2119 context" class="RFC2119">SHALL
|
|
NOT</em>, <em title="SHOULD in RFC2119 context"
|
|
class="RFC2119">SHOULD</em>, <em
|
|
title="SHOULD NOT in RFC2119 context" class="RFC2119">SHOULD
|
|
NOT</em>, <em title="RECOMMENDED in RFC2119 context"
|
|
class="RFC2119">RECOMMENDED</em>, <em
|
|
title="MAY in RFC2119 context" class="RFC2119">MAY</em>, and <em
|
|
title="OPTIONAL in RFC2119 context" class="RFC2119">OPTIONAL</em>
|
|
in this specification are to be interpreted as described in <a
|
|
href="#RFC2119">[IETF RFC 2119]</a>.</p>
|
|
|
|
<p>The terms <em title="BASE URI in RFC2119 context"
|
|
class="RFC2119">BASE URI</em> and <em
|
|
title="RELATIVE URI in RFC2119 context" class="RFC2119">RELATIVE
|
|
URI</em> are used in this specification as they are defined in <a
|
|
href="#RFC2396">[IETF RFC 2396]</a>.</p>
|
|
|
|
<p>Any section that is not marked as 'informative' is
|
|
normative.</p>
|
|
</div>
|
|
|
|
<div class="div1">
|
|
<h2><a name="d3e274" id="d3e274" />2 Summary</h2>
|
|
|
|
<p>This section is informative.</p>
|
|
|
|
<p>This document describes a loosely coupled architecture for
|
|
multimodal user interfaces, which allows for co-resident and
|
|
distributed implementations, and focuses on the role of markup and
|
|
scripting, and the use of well defined interfaces between its
|
|
constituents.</p>
|
|
</div>
|
|
|
|
<div class="div1">
|
|
<h2><a name="overview" id="overview" />3 Overview</h2>
|
|
|
|
<p>This section is informative.</p>
|
|
|
|
<p>This document describes the architecture of the Multimodal
|
|
Interaction (MMI) framework <a href="#MMIF">[MMIF]</a> and the
|
|
interfaces between its constituents. The MMI Working Group is aware
|
|
that multimodal interfaces are an area of active research and that
|
|
commercial implementations are only beginning to emerge. Therefore
|
|
we do not view our goal as standardizing a hypothetical existing
|
|
common practice, but rather providing a platform to facilitate
|
|
innovation and technical development. Thus the aim of this design
|
|
is to provide a general and flexible framework providing
|
|
interoperability among modality-specific components from different
|
|
vendors - for example, speech recognition from one vendor and
|
|
handwriting recognition from another. This framework places very
|
|
few restrictions on the individual components, but instead focuses
|
|
on providing a general means for communication, plus basic
|
|
infrastructure for application control and platform services.</p>
|
|
|
|
<p>Our framework is motivated by several basic design goals:</p>
|
|
|
|
<ul>
|
|
<li>Encapsulation. The architecture should make no assumptions
|
|
about the internal implementation of components, which will be
|
|
treated as black boxes.</li>
|
|
|
|
<li>Distribution. The architecture should support both distributed
|
|
and co-hosted implementations.</li>
|
|
|
|
<li>Extensibility. The architecture should facilitate the
|
|
integration of new modality components. For example, given an
|
|
existing implementation with voice and graphics components, it
|
|
should be possible to add a new component (for example, a biometric
|
|
security component) without modifying the existing components.</li>
|
|
|
|
<li>Recursiveness. The architecture should allow for nesting, so
|
|
that an instance of the framework consisting of several components
|
|
can be packaged up to appear as a single component to a
|
|
higher-level instance of the architecture.</li>
|
|
|
|
<li>Modularity. The architecture should provide for the separation
|
|
of data, control, and presentation.</li>
|
|
</ul>
|
|
|
|
<p>Even though multimodal interfaces are not yet common, the
|
|
software industry as a whole has considerable experience with
|
|
architectures that can accomplish these goals. Since the 1980s, for
|
|
example, distributed message-based systems have been common. They
|
|
have been used for a wide range of tasks, including in particular
|
|
high-end telephony systems. In this paradigm, the overall system is
|
|
divided up into individual components which communicate by sending
|
|
messages over the network. Since the messages are the only means of
|
|
communication, the internals of components are hidden and the
|
|
system may be deployed in a variety of topologies, either
|
|
distributed or co-located. One specific instance of this type of
|
|
system is the DARPA Hub Architecture, also known as the Galaxy
|
|
Communicator Software Infrastructure <a
|
|
href="#Communicator">[Galaxy]</a>. This is a distributed,
|
|
message-based, hub-and-spoke infrastructure designed for
|
|
constructing spoken dialogue systems. It was developed in the late
|
|
1990's and early 2000's under funding from DARPA. This
|
|
infrastructure includes a program called the Hub, together with
|
|
servers which provide functions such as speech recognition, natural
|
|
language processing, and dialogue management. The servers
|
|
communicate with the Hub and with each other using key-value
|
|
structures called frames.</p>
|
|
|
|
<p>Another recent architecture that is relevant to our concerns is
|
|
the model-view-controller (MVC) paradigm. This is a well known
|
|
design pattern for user interfaces in object oriented programming
|
|
languages, and has been widely used with languages such as Java,
|
|
Smalltalk, C, and C++. The design pattern proposes three main
|
|
parts: <em>a Data Model</em> that represents the underlying logical
|
|
structure of the data and associated integrity constraints, one or
|
|
more <em>Views</em> which correspond to the objects that the user
|
|
directly interacts with, and <em>a Controller</em> which sits
|
|
between the data model and the views. The separation between data
|
|
and user interface provides considerable flexibility in how the
|
|
data is presented and how the user interacts with that data. While
|
|
the MVC paradigm has been traditionally applied to graphical user
|
|
interfaces, it lends itself to the broader context of multimodal
|
|
interaction where the user is able to use a combination of visual,
|
|
aural and tactile modalities.</p>
|
|
</div>
|
|
|
|
<div class="div1">
|
|
<h2><a name="Design" id="Design" />4 Design versus Run-Time
|
|
considerations</h2>
|
|
|
|
<p>This section is informative.</p>
|
|
|
|
<p>In discussing the design of MMI systems, it is important to keep
|
|
in mind the distinction between the design-time view (i.e., the
|
|
markup) and the run-time view (the software that executes the
|
|
markup). At the design level, we assume that multimodal
|
|
applications will take the form of multiple documents from
|
|
different namespaces. In many cases, the different namespaces and
|
|
markup languages will correspond to different modalities, but we do
|
|
not require this. A single language may cover multiple modalities
|
|
and there may be multiple languages for a single modality.</p>
|
|
|
|
<p>At runtime, the MMI architecture features loosely coupled
|
|
software constituents that may be either co-resident on a device or
|
|
distributed across a network. In keeping with the loosely-coupled
|
|
nature of the architecture, the constituents do not share context
|
|
and communicate only by exchanging events. The nature of these
|
|
constituents and the APIs between them is discussed in more detail
|
|
in Sections 3-5, below. Though nothing in the MMI architecture
|
|
requires that there be any particular correspondence between the
|
|
design-time and run-time views, in many cases there will be a
|
|
specific software component responsible for each different markup
|
|
language (namespace).</p>
|
|
|
|
<div class="div2">
|
|
<h3><a name="d3e327" id="d3e327" />4.1 Markup and The Design-Time
|
|
View</h3>
|
|
|
|
<p>At the markup level, an application consists of multiple
|
|
documents. A single document may contain markup from different
|
|
namespaces if the interaction of those namespaces has been defined.
|
|
By the principle of encapsulation, however, the internal structure
|
|
of documents is invisible at the MMI level, which defines only how
|
|
the different documents communicate. One document has a special
|
|
status, namely the Root or Controller Document, which contains
|
|
markup defining the interaction between the other documents. Such
|
|
markup is called Interaction Manager markup. The other documents
|
|
are called Presentation Documents, since they contain markup to
|
|
interact directly with the user. The Controller Document may
|
|
consist solely of Interaction Manager markup (for example a state
|
|
machine defined in CCXML <a href="#CCXML">[CCXML]</a> or SCXML <a
|
|
href="#SCXML">[SCXML]</a>) or it may contain Interaction Manager
|
|
markup combined with presentation or other markup. As an example of
|
|
the latter design, consider a multimodal application in which a
|
|
CCXML document provides call control functionality as well as the
|
|
flow control for the various Presentation documents. Similarly, an
|
|
SCXML flow control document could contain embedded presentation
|
|
markup in addition to its native Interaction Management markup.</p>
|
|
|
|
<p>These relationships are recursive, so that any Presentation
|
|
Document may serve as the Controller Document for another set of
|
|
documents. This nested structure is similar to 'Russian Doll' model
|
|
of Modality Components, described below in <a
|
|
href="#Runtime"><b>4.2 Software Constituents and The Run-Time
|
|
View</b></a>.</p>
|
|
|
|
<p>The different documents are loosely coupled and co-exist without
|
|
interacting directly. Note in particular that there are no shared
|
|
variables that could be used to pass information between them.
|
|
Instead, all runtime communication is handled by events, as
|
|
described below in <a href="#Interfaces"><b>6 Interface between the
|
|
Interaction Manager and the Modality Components</b></a>. Note,
|
|
however, that this only applies to non-root documents. The IM,
|
|
which loads the root document, interacts with "other components".
|
|
I.e., the IM (having the root-document) interacts directly through
|
|
life-cycle events with Modality Components (having different
|
|
documents and/or namespaces).</p>
|
|
|
|
<p>Furthermore, it is important to note that the asynchronicity of
|
|
the underlying communication mechanism does not impose the
|
|
requirement that the markup languages present a purely asynchronous
|
|
programming model to the developer. Given the principle of
|
|
encapsulation, markup languages are not required to reflect
|
|
directly the architecture and APIs defined here. As an example,
|
|
consider an implementation containing a Modality Component
|
|
providing Text-to-Speech (TTS) functionality. This Component must
|
|
communicate with the Interaction Manager via asynchronous events
|
|
(see <a href="#Runtime"><b>4.2 Software Constituents and The
|
|
Run-Time View</b></a>). In a typical implementation, there would
|
|
likely be events to start a TTS play and to report the end of the
|
|
play, etc. However, the markup and scripts that were used to author
|
|
this system might well offer only a synchronous "play TTS" call, it
|
|
being the job of the underlying implementation to convert that
|
|
synchronous call into the appropriate sequence of asynchronous
|
|
events. In fact, there is no requirement that the TTS resource be
|
|
individually accessible at all. It would be quite possible for the
|
|
markup to present only a single "play TTS and do speech
|
|
recognition" call, which the underlying implementation would
|
|
realize as a series of asynchronous events involving multiple
|
|
Components.</p>
|
|
|
|
<p>Existing languages such as HTML may be used as either the
|
|
Controller Documents or as Presentation Documents. Further examples
|
|
of potential markup components are given in <a
|
|
href="#ConstituentExamples"><b>5.2.7 Examples</b></a></p>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a name="Runtime" id="Runtime" />4.2 Software Constituents and
|
|
The Run-Time View</h3>
|
|
|
|
<p>At the core of the MMI runtime architecture is the distinction
|
|
between the Interaction Manager (IM) and the Modality Components,
|
|
which is similar to the distinction between the Controller Document
|
|
and the Presentation Documents. The Interaction Manager interprets
|
|
the Controller Document while the individual Modality Components
|
|
are responsible for specific tasks, particularly handling input and
|
|
output in the various modalities, such as speech, pen, video,
|
|
etc.</p>
|
|
|
|
<p>The Interaction Manager receives all the events that the various
|
|
Modality Components generate. Those events may be commands or
|
|
replies to commands, and it is up to the Interaction Manager to
|
|
decide what to do with them, i.e., what events to generate in
|
|
response to them. In general, the MMI architecture follows a
|
|
'targetless' event model. That is, the Component that raises an
|
|
event does not specify its destination. Rather, it passes it up to
|
|
the Runtime Framework, which will pass it to the Interaction
|
|
Manager. The IM, in turn, decides whether to forward the event to
|
|
other Components, or to generate a different event, etc.</p>
|
|
|
|
<p>Modality Components are black boxes, required only to implement
|
|
the Modality Component Interface API which is described below. This
|
|
API allows the Modality Components to communicate with the IM and
|
|
thus indirectly with each other, since the IM is responsible for
|
|
delivering events/messages among the Components. Since the
|
|
internals of a Component are hidden, it is possible for an
|
|
Interaction Manager and a set of Components to present themselves
|
|
as a Component to a higher-level Interaction Manager. All that is
|
|
required is that the IM implement the Component API. The result is
|
|
a "Russian Doll" model in which Components may be nested inside
|
|
other Components to an arbitrary depth. Nesting components in this
|
|
manner is one way to produce a 'complex' Modality Component, namely
|
|
one that handles multiple modalities simultaneously. However, it is
|
|
also possible to produce complex Modality Components without
|
|
nesting, as discussed in <a href="#ModalityComponents"><b>5.2.3 The
|
|
Modality Components</b></a>.</p>
|
|
|
|
<p>In addition to the Interaction Manager and the modality
|
|
components, there is a Runtime Framework that provides
|
|
infrastructure support, in particular a transport layer which
|
|
delivers events among the components.</p>
|
|
|
|
<p>Because we are using the term 'Component' to refer to a specific
|
|
set of entities in our architecture, we will use the term
|
|
'Constituent' as a cover term for all the elements in our
|
|
architecture which might normally be called 'software
|
|
components'.</p>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a name="Relationship_to_EMMA" id="Relationship_to_EMMA" />4.3
|
|
Relationship to EMMA</h3>
|
|
|
|
<p>The Extended Multimodal Annotation Language <a
|
|
href="#EMMA">[EMMA]</a>, is a set of specifications for multimodal
|
|
systems, and provides details of an XML markup language for
|
|
containing and annotating the interpretation of user input. For
|
|
example, a user of a multimodal application might use both speech
|
|
to express a command, and keystroke gesture to select or draw
|
|
command parameters. The Speech Recognition Modality would express
|
|
the user command using EMMA to indicate the input source (speech).
|
|
The Pen Gesture Modality would express the command parameters using
|
|
EMMA to indicate the input source (pen gestures). Both modalities
|
|
may include timing information in the EMMA notation. Using the
|
|
timing information, a fusion module combines the speech and pen
|
|
gesture information into a single EMMA notation representing both
|
|
the command and its parameters. The use of EMMA enables the
|
|
separation of recognition process from the information fusion
|
|
process, and thus enables reusable recognition modalities and
|
|
general purpose information fusion algorithms.</p>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div1">
|
|
<h2><a name="OverviewConstituents" id="OverviewConstituents" />5
|
|
Overview of Architecture</h2>
|
|
|
|
<p>Here is a list of the Constituents of the MMI architecture. They
|
|
are discussed in more detail below.</p>
|
|
|
|
<ul>
|
|
<li>the Interaction Manager, which coordinates the different
|
|
modalities. It is the Controller in the MVC paradigm.</li>
|
|
|
|
<li>the Data Component, which provides the common data model and
|
|
represents the Model in the MVC paradigm.</li>
|
|
|
|
<li>the Modality Components, which provide modality-specific
|
|
interaction capabilities. They are the Views in the MVC
|
|
paradigm.</li>
|
|
|
|
<li>the Runtime Framework, which provides the basic infrastructure
|
|
and enables communication among the other Constituents.</li>
|
|
</ul>
|
|
|
|
<div class="div2">
|
|
<h3><a name="ArchDiagram" id="ArchDiagram" />5.1 Run-Time
|
|
Architecture Diagram</h3>
|
|
|
|
<img class="center" src="Images/RevisedArchDiagram.png"
|
|
alt="architecture diagram" /></div>
|
|
|
|
<div class="div2">
|
|
<h3><a name="Constitents" id="Constitents" />5.2 The
|
|
Constituents</h3>
|
|
|
|
This section presents the responsibilities of the various
|
|
constituents of the MMI architecture.
|
|
|
|
<div class="div3">
|
|
<h4><a name="d3e395" id="d3e395" />5.2.1 The Interaction
|
|
Manager</h4>
|
|
|
|
<p>All life-cycle events that the Modality Components generate <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> be
|
|
delivered to the Interaction Manager. All life-cycle events that
|
|
are delivered to Modality Components <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> be sent
|
|
by the Interaction Manager.</p>
|
|
|
|
<p>Due to the Russian Doll model, Modality Components <em
|
|
title="MAY in RFC2119 context" class="RFC2119">MAY</em> contain
|
|
their own Interaction Managers to handle their internal events.
|
|
However these Interaction Managers are not visible to the top level
|
|
Runtime Framework or Interaction Manager.</p>
|
|
|
|
<p>If the Interaction Manager does not contain an explicit handler
|
|
for an event, it <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> respect any default behavior that has
|
|
been established for the event. If there is no default behavior,
|
|
the Interaction Manager <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> ignore the event. (In effect, the
|
|
Interaction Manager's default handler for all events is to ignore
|
|
them.)</p>
|
|
|
|
<p>The following paragraph is informative.</p>
|
|
|
|
<p>Normally there will be specific markup associated with the IM
|
|
instructing it how to respond to events. This markup will thus
|
|
contain a lot of the most basic interaction logic of an
|
|
application. Existing languages such as SMIL, CCXML, SCXML, or
|
|
ECMAScript can be used for IM markup as an alternative to defining
|
|
special-purpose languages aimed specifically at multimodal
|
|
applications. The IM fulfills multiple functions. For example, it
|
|
is responsible for synchronization of data and focus, etc., across
|
|
different Modality Components as well as the higher-level
|
|
application flow that is independent of Modality Components. It
|
|
also maintains the high-level application data model and may handle
|
|
communication with external entities and back-end systems.
|
|
Logically these functions could be separated into separate
|
|
constituents and implementations may want to introduce internal
|
|
structure to the IM. However, for the purposes of this standard, we
|
|
leave the various functions rolled up in a single monolithic
|
|
Interaction Manager component. We note that state machine languages
|
|
such as SCXML are a good choice for authoring such a multi-function
|
|
component, since state machines can be composed. Thus it is
|
|
possible to define a high-level state machine representing the
|
|
overall application flow, with lower-level state machines nested
|
|
inside it handling the the cross-modality synchronization at each
|
|
phase of the higher-level flow.</p>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a name="d3e423" id="d3e423" />5.2.2 The Data Component</h4>
|
|
|
|
<p>This section is informative.</p>
|
|
|
|
<p>The Data Component is responsible for storing application-level
|
|
data. The Interaction Manager is a client of the Data Component and
|
|
is able to access and update it as part of its control flow logic,
|
|
but Modality Components do not have direct access to it. Since
|
|
Modality Components are black boxes, they may have their own
|
|
internal Data Components and may interact directly with backend
|
|
servers. However, the only way that Modality Components can share
|
|
data among themselves and maintain consistency is via the
|
|
Interaction Manager. It is therefore a good application design
|
|
practice to divide data into two logical classes: private data,
|
|
which is of interest only to a given modality component, and public
|
|
data, which is of interest to the Interaction Manager or to more
|
|
than one Modality Component. Private data may be managed as the
|
|
Modality Component sees fit, but all modification of public data,
|
|
including submission to back end servers, should be entrusted to
|
|
the Interaction Manager.</p>
|
|
|
|
<p>This specification does not define an interface between the Data
|
|
Component and the Interaction Manager. This amounts to treating the
|
|
Data Component as part of the Interaction Manager. (Note that this
|
|
means that the data access language will be whatever one the IM
|
|
provides.) The Data Component is shown with a dotted outline in the
|
|
diagram above, however, because it is logically distinct and could
|
|
be placed in a separate component.</p>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a name="ModalityComponents" id="ModalityComponents" />5.2.3
|
|
The Modality Components</h4>
|
|
|
|
<p>This section is informative.</p>
|
|
|
|
<p>Modality Components, as their name would indicate, are
|
|
responsible for controlling the various input and output modalities
|
|
on the device. They are therefore responsible for handling all
|
|
interaction with the user(s). Their only responsibility is to
|
|
implement the interface defined in <a href="#Interfaces"><b>6
|
|
Interface between the Interaction Manager and the Modality
|
|
Components</b></a>. Any further definition of their
|
|
responsibilities will be highly domain- and application-specific.
|
|
In particular we do not define a set of standard modalities or the
|
|
events that they should generate or handle. Platform providers are
|
|
allowed to define new Modality Components and are allowed to place
|
|
into a single Component functionality that might logically seem to
|
|
belong to two or more different modalities. Thus a platform could
|
|
provide a handwriting-and-speech Modality Component that would
|
|
accept simultaneous voice and pen input. Such combined Components
|
|
permit a much tighter coupling between the two modalities than the
|
|
loose interface defined here. Furthermore, modality components may
|
|
be used to perform general processing functions not directly
|
|
associated with any specific interface modality, for example,
|
|
dialog flow control or natural language processing.</p>
|
|
|
|
<p>In most cases, there will be specific markup in the application
|
|
corresponding to a given modality, specifying how the interaction
|
|
with the user should be carried out. However, we do not require
|
|
this and specifically allow for a markup-free modality component
|
|
whose behavior is hard-coded into its software.</p>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a name="d3e443" id="d3e443" />5.2.4 The Runtime Framework</h4>
|
|
|
|
<p>The Runtime Framework is a cover term for all the infrastructure
|
|
services that are necessary for successful execution of a
|
|
multimodal application. This includes starting the components,
|
|
handling communication, and logging, etc. For the most part, this
|
|
version of the specification leaves these functions to be defined
|
|
in a platform-specific way, but we do specifically define a
|
|
Transport Layer which handles communications between the
|
|
components.</p>
|
|
|
|
<div class="div4">
|
|
<h5><a name="d3e448" id="d3e448" />5.2.4.1 The Event Transport
|
|
Layer</h5>
|
|
|
|
<p>The Event Transport Layer is responsible for delivering events
|
|
among the IM and the Modality Components. Clearly, there are
|
|
multiple transport mechanisms (protocols) that can be used to
|
|
implement a Transport Layer and different mechanisms may be used to
|
|
communicate with different modality components. Thus the Event
|
|
Transport Layer consists of one or more transport mechanisms
|
|
linking the IM to the various Modality Components.</p>
|
|
|
|
<p>We place the following requirements on all transport
|
|
mechanisms:</p>
|
|
|
|
<ol>
|
|
<li>Events <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> be delivered reliably. In particular, the
|
|
event delivery mechanism <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> report an error if an event can not be
|
|
delivered, for example if the destination endpoint is
|
|
unavailable.</li>
|
|
|
|
<li>Events <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> be delivered to the destination in the
|
|
order in which the source generated them. There is no guarantee on
|
|
the delivery order of events generated by different sources. For
|
|
example, if Modality Component M1 generates events E1 and E2 in
|
|
that order, while Modality Component M2 generates E3 and then E4,
|
|
we require that E1 be delivered to the Runtime Framework before E2
|
|
and that E3 be delivered before E4, but there is no guarantee on
|
|
the ordering of E1 or E2 versus E3 or E4.</li>
|
|
</ol>
|
|
|
|
<p>For a sample definition of a Transport Layer relying on HTTP,
|
|
see <a href="#HTTPTransport"><b>F HTTP transport of MMI lifecycle
|
|
events</b></a>. This definition is provided as an example only.</p>
|
|
|
|
<div class="div5">
|
|
<h6><a name="security" id="security" />5.2.4.1.1 Event and
|
|
Information Security</h6>
|
|
|
|
<p>This section is informative.</p>
|
|
|
|
<p>Events will often carry sensitive information, such as bank
|
|
account numbers or health care information. In addition events must
|
|
also be reliable to both sides of transaction: for example, if an
|
|
event carries an assent to a financial transaction, both sides of
|
|
the transaction must be able to rely on that assent.</p>
|
|
|
|
<p>We do not currently specify delivery mechanisms or internal
|
|
security safeguards to be used by the Modality Components and the
|
|
Interaction Manager. However, we believe that any secure system
|
|
will have to meet the following requirements at a minimum:</p>
|
|
|
|
<p>The following two optional requirements can be met by using the
|
|
W3C's XML-Signature Syntax and Processing specification <a
|
|
href="#XMLSig">[XMLSig]</a>.</p>
|
|
|
|
<ol>
|
|
<li>Authentication. The event delivery mechanism should be able to
|
|
ensure that the identity of components in an interaction are
|
|
known.</li>
|
|
|
|
<li>Integrity. The event delivery mechanism should be able to
|
|
ensure that the contents of events have not been altered in
|
|
transit.
|
|
|
|
<p>The remaining optional requirements for event delivery and
|
|
information security can be met by following other
|
|
industry-standard procedures.</p>
|
|
</li>
|
|
|
|
<li>Authorization. A component should provide a method to ensure
|
|
only authorized components can connect to it.</li>
|
|
|
|
<li>Privacy. The event delivery mechanism should provide a method
|
|
to keep the message contents secure from any unauthorized access
|
|
while in transit.</li>
|
|
|
|
<li>Non-repudiation. The event delivery mechanism, in conjunction
|
|
with the components, may provide a method to ensure that if a
|
|
message is sent from one constituent to another, the originating
|
|
constituent cannot repudiate the message that it sent and that the
|
|
receiving constituent cannot repudiate that the message was
|
|
received.</li>
|
|
</ol>
|
|
|
|
<p>Multiple protocols may be necessary to implement these
|
|
requirements. For example, TCP/IP and HTTP provide reliable event
|
|
delivery, but additional protocols such as TLS or HTTPS could be
|
|
required to meet security requirements.</p>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a name="d3e502" id="d3e502" />5.2.5 System and OS
|
|
Security</h4>
|
|
|
|
<p>This section is informative.</p>
|
|
|
|
<p>This architecture does not and will not specify the internal
|
|
security requirements of a Modality Component or Runtime
|
|
Framework.</p>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a name="d3e509" id="d3e509" />5.2.6 Media stream handling</h4>
|
|
|
|
<p>Media streams do not typically flow through the Interaction
|
|
Manager. This specification does not specify how media connections
|
|
are established, as the main focus of this specification is the
|
|
flow of control data. However, all control data logically sent
|
|
between modality components <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> flow through the Interaction Manager.</p>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a name="ConstituentExamples" id="ConstituentExamples" />5.2.7
|
|
Examples</h4>
|
|
|
|
<p>This section is informative.</p>
|
|
|
|
<p>For the sake of concreteness, here are some examples of
|
|
components that could be implemented using existing languages. Note
|
|
that we are mixing the design-time and run-time views here, since
|
|
it is the implementation of the language (the browser) that serves
|
|
as the run-time component.</p>
|
|
|
|
<ul>
|
|
<li>CCXML <a href="#CCXML">[CCXML]</a>could be used as both the
|
|
Controller Document and the Interaction Manager language, with the
|
|
CCXML interpreter serving as the Runtime Framework and Interaction
|
|
Manager.</li>
|
|
|
|
<li>SCXML <a href="#SCXML">[SCXML]</a> could be used as the
|
|
Controller Document and Interaction Manager language</li>
|
|
|
|
<li>In an integrated multimodal browser, the markup language that
|
|
provided the document root tag would define the Controller Document
|
|
while the associated scripting language could serve as the
|
|
Interaction Manager.</li>
|
|
|
|
<li>HTML <a href="#HTML">[HTML]</a> could be used as the markup for
|
|
a Modality Component.</li>
|
|
|
|
<li>VoiceXML <a href="#VoiceXML">[VoiceXML]</a>could be used as the
|
|
markup for a Modality Component.</li>
|
|
|
|
<li>SVG <a href="#SVG">[SVG]</a> could be used as the markup for a
|
|
Modality Component.</li>
|
|
|
|
<li>SMIL <a href="#SMIL">[SMIL]</a>could be used as the markup for
|
|
a Modality Component.</li>
|
|
</ul>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div1">
|
|
<h2><a name="Interfaces" id="Interfaces" />6 Interface between the
|
|
Interaction Manager and the Modality Components</h2>
|
|
|
|
<p>The most important interface in this architecture is the one
|
|
between the Modality Components and the Interaction Manager.
|
|
Modality Components communicate with the IM via asynchronous
|
|
events. Constituents <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> be able to send events and to handle
|
|
events that are delivered to them asynchronously. It is not
|
|
required that Constituents use these events internally since the
|
|
implementation of a given Constituent is black box to the rest of
|
|
the system. In general, it is expected that Constituents will send
|
|
events both automatically (i.e., as part of their implementation)
|
|
and under mark-up control.</p>
|
|
|
|
<p>The majority of the events defined here come in request/response
|
|
pairs. That is, one party (either the IM or an MC) sends a request
|
|
and the other returns a response. (The exceptions are the
|
|
ExtensionNotification, StatusRequest and StatusResponse events,
|
|
which can be sent by either party.) In each case it is specified
|
|
which party sends the request and which party returns the response.
|
|
If the wrong party sends a request or response, or if the request
|
|
or response is sent under the wrong conditions (e.g. response
|
|
without a previous request) the behavior of the receiving party is
|
|
undefined. In the descriptions below, we say that the originating
|
|
party <em title=""MAY" in RFC2119 context"
|
|
class="RFC2119">"MAY"</em> send the request, because it is up to
|
|
the internal logic of the originating party to decide if it wants
|
|
to invoke the behavior that the request would trigger. On the other
|
|
hand, we say that the receiving party <em
|
|
title=""MUST" in RFC2119 context"
|
|
class="RFC2119">"MUST"</em> send the response, because it is
|
|
mandatory to send the response if and when the request is
|
|
received.</p>
|
|
|
|
<div class="div2">
|
|
<h3><a name="ComponentInterface" id="ComponentInterface" />6.1
|
|
Common Event Fields</h3>
|
|
|
|
<p>The concept of 'context' is basic to these events described
|
|
below. A context represents a single extended interaction with zero
|
|
or more users across one or more modality components. In a simple
|
|
unimodal case, a context can be as simple as a phone call or SSL
|
|
session. Multimodal cases are more complex, however, since the
|
|
various modalities may not be all used at the same time. For
|
|
example, in a voice-plus-web interaction, e.g., web sharing with an
|
|
associated VoIP call, it would be possible to terminate the web
|
|
sharing and continue the voice call, or to drop the voice call and
|
|
continue via web chat. In these cases, a single context persists
|
|
across various modality configurations. In general, the 'context'
|
|
<em title=" SHOULD in RFC2119 context" class="RFC2119">SHOULD</em>
|
|
cover the longest period of interaction over which it would make
|
|
sense for components to store information.</p>
|
|
|
|
<p>For examples of the concrete XML syntax for all these events,
|
|
see <a href="#EventExamples"><b>B Examples of Life-Cycle
|
|
Events</b></a></p>
|
|
|
|
<p>The following common fields are shared by multiple life-cycle
|
|
events:</p>
|
|
|
|
<div class="div3">
|
|
<h4><a name="ContextField" id="ContextField" />6.1.1 Context</h4>
|
|
|
|
<p>A URI that <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> be unique for the lifetime of the system.
|
|
It is used to identify this interaction. All events relating to a
|
|
given interaction <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> use the same context URI. Events
|
|
containing a different context URI <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> be
|
|
interpreted as part of other, unrelated, interactions.</p>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a name="SourceField" id="SourceField" />6.1.2 Source</h4>
|
|
|
|
<p>A URI representing the address of the sender of the event. The
|
|
recipient of the event <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> be able to send an event back to the
|
|
sender by using this value as the 'target' of a message.</p>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a name="TargetField" id="TargetField" />6.1.3 Target</h4>
|
|
|
|
<p>A URI that <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> represent the address to which the event
|
|
will be delivered.</p>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a name="RequestIDField" id="RequestIDField" />6.1.4
|
|
RequestID</h4>
|
|
|
|
<p>A unique identifier for a Request/Response pair. Most life-cycle
|
|
events come in Request/Response pairs that share a common
|
|
RequestID. For any such pair, the RequestID in the Response event
|
|
<em title="MUST in RFC2119 context" class="RFC2119">MUST</em> match
|
|
the RequestID in the request event. The RequestID for such a pair
|
|
<em title="MUST in RFC2119 context" class="RFC2119">MUST</em> be
|
|
unique within the given context.</p>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a name="StatusField" id="StatusField" />6.1.5 Status</h4>
|
|
|
|
<p>An enumeration of 'Success' and 'Failure'. The Response event of
|
|
a Request/Response pair <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> use this field to report whether it
|
|
succeeded in carrying out the request.</p>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a name="StatusInfoField" id="StatusInfoField" />6.1.6
|
|
StatusInfo</h4>
|
|
|
|
<p>The Response event of a Request/Response pair <em
|
|
title="MAY in RFC2119 context" class="RFC2119">MAY</em> use this
|
|
field to provide additional status information.</p>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a name="DataField" id="DataField" />6.1.7 Data</h4>
|
|
|
|
<p>Any event <em title="MAY in RFC2119 context"
|
|
class="RFC2119">MAY</em> use this field to contain arbitrary data.
|
|
The format and meaning of this data is application-specific.</p>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a name="ConfidentialField" id="ConfidentialField" />6.1.8
|
|
Confidential</h4>
|
|
|
|
<p>Any event <em title="MAY in RFC2119 context"
|
|
class="RFC2119">MAY</em> use this field to indicate whether the
|
|
contents of this event are confidential. The default value is
|
|
'false'. If the value is 'true', the Interaction Manager and
|
|
Modality Component implementations <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> not log
|
|
the information or make it available in any way to third parties
|
|
unless explicitly instructed to do so by the author of the
|
|
application.</p>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a name="LifeCycleEvents" id="LifeCycleEvents" />6.2 Standard
|
|
Life Cycle Events</h3>
|
|
|
|
<p>The Multimodal Architecture defines the following basic
|
|
life-cycle events which the Interaction Manager and Modality
|
|
Components <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> support. These events allow the
|
|
Interaction Manager to invoke modality components and receive
|
|
results from them. They thus form the basic interface between the
|
|
IM and the Modality components. Note that the ExtensionNotification
|
|
event offers extensibility since it contains arbitrary content and
|
|
can be raised by either the IM or the Modality Components at any
|
|
time once the context has been established. For example, an
|
|
application relying on speech recognition could use the 'Extension'
|
|
event to communicate recognition results or the fact that speech
|
|
had started, etc.</p>
|
|
|
|
<p>In the definitions below, all fields are mandatory, unless
|
|
explicitly stated to be optional.</p>
|
|
|
|
<div class="div3">
|
|
<h4><a name="d3e666" id="d3e666" />6.2.1
|
|
NewContextRequest/NewContextResponse</h4>
|
|
|
|
<p>A Modality Component <em title="MAY in RFC2119 context"
|
|
class="RFC2119">MAY</em> send a NewContextRequest to the IM to
|
|
request that a new context be created. If this event is sent, the
|
|
IM <em title="MUST in RFC2119 context" class="RFC2119">MUST</em>
|
|
respond with the NewContextResponse event. The NewContextResponse
|
|
event <em title="MUST ONLY in RFC2119 context" class="RFC2119">MUST
|
|
ONLY</em> be sent in response to the NewContextRequest event. Note
|
|
that the IM <em title="MAY in RFC2119 context"
|
|
class="RFC2119">MAY</em> create a new context without a previous
|
|
NewContextRequest by sending a PrepareRequest or StartRequest
|
|
containing a new context ID to the Modality Components. Furthermore
|
|
the IM may respond with the same context in response to
|
|
NewContextRequests from different (multiple) Modality Components,
|
|
since the interaction can be started by different Modality
|
|
Components independently.</p>
|
|
|
|
<div class="div4">
|
|
<h5><a name="d3e683" id="d3e683" />6.2.1.1 NewContextRequest
|
|
Properties</h5>
|
|
|
|
<ul>
|
|
<li><code>RequestID</code>. See <a href="#RequestIDField"><b>6.1.4
|
|
RequestID</b></a>. A newly generated identifier used to identify
|
|
this request.</li>
|
|
|
|
<li><code>Source</code> See <a href="#SourceField"><b>6.1.2
|
|
Source</b></a>.</li>
|
|
|
|
<li><code>Target</code> See <a href="#TargetField"><b>6.1.3
|
|
Target</b></a>.</li>
|
|
|
|
<li><code>Data</code> Optional. See <a href="#DataField"><b>6.1.7
|
|
Data</b></a>.</li>
|
|
|
|
<li><code>Confidential</code> Optional. See <a
|
|
href="#ConfidentialField"><b>6.1.8 Confidential</b></a>.</li>
|
|
</ul>
|
|
</div>
|
|
|
|
<div class="div4">
|
|
<h5><a name="d3e717" id="d3e717" />6.2.1.2 NewContextResponse
|
|
Properties</h5>
|
|
|
|
<ul>
|
|
<li><code>RequestID</code>. See <a href="#RequestIDField"><b>6.1.4
|
|
RequestID</b></a>. This <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> match the RequestID in the
|
|
NewContextRequest event.</li>
|
|
|
|
<li><code>Status</code> See <a href="#StatusField"><b>6.1.5
|
|
Status</b></a>. If IM has accepted the NewContextRequest, it <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> set this
|
|
field to Success and <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> include a new context identifier.</li>
|
|
|
|
<li><code>Context</code> See <a href="#ContextField"><b>6.1.1
|
|
Context</b></a>. A newly created context identifier. This field <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> be empty
|
|
if status is Failure.</li>
|
|
|
|
<li><code>StatusInfo</code> Optional. See <a
|
|
href="#StatusInfoField"><b>6.1.6 StatusInfo</b></a>.</li>
|
|
|
|
<li><code>Source</code> See <a href="#SourceField"><b>6.1.2
|
|
Source</b></a>.</li>
|
|
|
|
<li><code>Target</code> See <a href="#TargetField"><b>6.1.3
|
|
Target</b></a>.</li>
|
|
|
|
<li><code>Data</code> Optional. See <a href="#DataField"><b>6.1.7
|
|
Data</b></a>.</li>
|
|
|
|
<li><code>Confidential</code> Optional. See <a
|
|
href="#ConfidentialField"><b>6.1.8 Confidential</b></a>.</li>
|
|
</ul>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a name="d3e781" id="d3e781" />6.2.2
|
|
PrepareRequest/PrepareResponse</h4>
|
|
|
|
<p>The IM <em title="MAY in RFC2119 context"
|
|
class="RFC2119">MAY</em> send a PrepareRequest to allow the
|
|
Modality Components to pre-load markup and prepare to run. Modality
|
|
Components are not required to take any particular action in
|
|
response to this event, but they <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> return a
|
|
PrepareResponse event. Modality Components that return a
|
|
PrepareResponse event with Status of 'Success' <em
|
|
title="SHOULD in RFC2119 context" class="RFC2119">SHOULD</em> be
|
|
ready to run with close to 0 delay upon receipt of the
|
|
StartRequest.</p>
|
|
|
|
<p>The Interaction Manager <em title="MAY in RFC2119 context"
|
|
class="RFC2119">MAY</em> send multiple PrepareRequest events to a
|
|
Modality Component for the same Context before sending a
|
|
StartRequest. Each request <em title="MAY in RFC2119 context"
|
|
class="RFC2119">MAY</em> reference a different ContentURL or
|
|
contain different in-line Content. When it receives multiple
|
|
PrepareRequests, the Modality Component <em
|
|
title="SHOULD in RFC2119 context" class="RFC2119">SHOULD</em>
|
|
prepare to run any of the specified content.</p>
|
|
|
|
<div class="div4">
|
|
<h5><a name="d3e806" id="d3e806" />6.2.2.1 PrepareRequest
|
|
Properties</h5>
|
|
|
|
<ul>
|
|
<li><code>RequestID</code>. See <a href="#RequestIDField"><b>6.1.4
|
|
RequestID</b></a>. A newly generated identifier used to identify
|
|
this request.</li>
|
|
|
|
<li><code>Context</code> See <a href="#ContextField"><b>6.1.1
|
|
Context</b></a>. Note that the IM <em title="MAY
|
|
in RFC2119 context" class="RFC2119">MAY</em> use the same context
|
|
value in multiple PrepareRequest events when it wishes to execute
|
|
multiple instances of markup in the same context.</li>
|
|
|
|
<li><code>ContentURL</code> Optional URL of the content that the
|
|
Modality Component <em title="SHOULD in RFC2119 context"
|
|
class="RFC2119">SHOULD</em> prepare to execute.</li>
|
|
|
|
<li><code>Content</code> Optional Inline markup that the Modality
|
|
Component <em title="SHOULD in RFC2119 context"
|
|
class="RFC2119">SHOULD</em> prepare to execute.</li>
|
|
|
|
<li><code>Source</code> See <a href="#SourceField"><b>6.1.2
|
|
Source</b></a>.</li>
|
|
|
|
<li><code>Target</code> See <a href="#TargetField"><b>6.1.3
|
|
Target</b></a>.</li>
|
|
|
|
<li><code>Data</code> Optional. See <a href="#DataField"><b>6.1.7
|
|
Data</b></a>.</li>
|
|
|
|
<li><code>Confidential</code> Optional. See <a
|
|
href="#ConfidentialField"><b>6.1.8 Confidential</b></a>.</li>
|
|
</ul>
|
|
|
|
<p>The IM <em title="MUST NOT in RFC2119 context"
|
|
class="RFC2119">MUST NOT</em> specify both the ContentURL and
|
|
Content in a single PrepareRequest. The IM <em
|
|
title="MAY in RFC2119 context" class="RFC2119">MAY</em> leave both
|
|
<code>contentURL</code> and <code>content</code> empty. In such a
|
|
case, the Modality Component <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> revert to its default behavior. For
|
|
example, this behavior could consist of returning an error event or
|
|
of running a preconfigured or hard-coded script.</p>
|
|
</div>
|
|
|
|
<div class="div4">
|
|
<h5><a name="d3e880" id="d3e880" />6.2.2.2 PrepareResponse
|
|
Properties</h5>
|
|
|
|
<ul>
|
|
<li><code>RequestID</code>. See <a href="#RequestIDField"><b>6.1.4
|
|
RequestID</b></a>. This <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> match the RequestID in the PrepareRequest
|
|
event.</li>
|
|
|
|
<li><code>Context</code> See <a href="#ContextField"><b>6.1.1
|
|
Context</b></a>. This <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> match the value in the PrepareRequest
|
|
event.</li>
|
|
|
|
<li><code>Status</code> See <a href="#StatusField"><b>6.1.5
|
|
Status</b></a>.</li>
|
|
|
|
<li><code>StatusInfo</code> Optional. See <a
|
|
href="#StatusInfoField"><b>6.1.6 StatusInfo</b></a>.</li>
|
|
|
|
<li><code>Source</code> See <a href="#SourceField"><b>6.1.2
|
|
Source</b></a>.</li>
|
|
|
|
<li><code>Target</code> See <a href="#TargetField"><b>6.1.3
|
|
Target</b></a>.</li>
|
|
|
|
<li><code>Data</code> Optional. See <a href="#DataField"><b>6.1.7
|
|
Data</b></a>.</li>
|
|
|
|
<li><code>Confidential</code> Optional. See <a
|
|
href="#ConfidentialField"><b>6.1.8 Confidential</b></a>.</li>
|
|
</ul>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a name="StartRequest" id="StartRequest" />6.2.3
|
|
StartRequest/StartResponse</h4>
|
|
|
|
<p>To invoke a modality component, the IM <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> send a
|
|
StartRequest. The Modality Component <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> return a
|
|
StartResponse event in response. The IM <em
|
|
title="MAY in RFC2119 context" class="RFC2119">MAY</em> include a
|
|
value in the ContentURL or Content field of this event. In this
|
|
case, the Modality Component <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> use this value.</p>
|
|
|
|
<p>If a Modality Component receives a new StartRequest while it is
|
|
executing a previous one, it <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> either cease execution of the previous
|
|
StartRequest and begin executing the content specified in the most
|
|
recent StartRequest, or reject the new StartRequest, returning a
|
|
StartResponse with status equal to 'Failure'.</p>
|
|
|
|
<div class="div4">
|
|
<h5><a name="d3e960" id="d3e960" />6.2.3.1 StartRequest
|
|
Properties</h5>
|
|
|
|
<ul>
|
|
<li><code>RequestID</code>. See <a href="#RequestIDField"><b>6.1.4
|
|
RequestID</b></a>. A newly generated identifier used to identify
|
|
this request.</li>
|
|
|
|
<li><code>Context</code> See <a href="#ContextField"><b>6.1.1
|
|
Context</b></a>. Note that the IM <em title="MAY
|
|
in RFC2119 context" class="RFC2119">MAY</em> use the same context
|
|
value in multiple StartRequest events when it wishes to execute
|
|
multiple instances of markup in the same context.</li>
|
|
|
|
<li><code>ContentURL</code> Optional URL of the content that the
|
|
Modality Component <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> attempt to execute.</li>
|
|
|
|
<li><code>Content</code> Optional Inline markup that the Modality
|
|
Component <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> attempt to execute.</li>
|
|
|
|
<li><code>Source</code> See <a href="#SourceField"><b>6.1.2
|
|
Source</b></a>.</li>
|
|
|
|
<li><code>Target</code> See <a href="#TargetField"><b>6.1.3
|
|
Target</b></a>.</li>
|
|
|
|
<li><code>Data</code> Optional. See <a href="#DataField"><b>6.1.7
|
|
Data</b></a>.</li>
|
|
|
|
<li><code>Confidential</code> Optional. See <a
|
|
href="#ConfidentialField"><b>6.1.8 Confidential</b></a>.</li>
|
|
</ul>
|
|
|
|
<p>The IM <em title="MUST NOT in RFC2119 context"
|
|
class="RFC2119">MUST NOT</em> specify both the ContentURL and
|
|
Content in a single StartRequest. The IM <em
|
|
title="MAY in RFC2119 context" class="RFC2119">MAY</em> leave both
|
|
contentURL and content empty. In such a case, the Modality
|
|
Component <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> run the content specified in the most
|
|
recent PrepareRequest in this context, if there is one. Otherwise
|
|
it <em title="MUST in RFC2119 context" class="RFC2119">MUST</em>
|
|
revert to its default behavior. For example, this behavior could
|
|
consist of returning an error event or of running a preconfigured
|
|
or hard-coded script.</p>
|
|
</div>
|
|
|
|
<div class="div4">
|
|
<h5><a name="d3e1031" id="d3e1031" />6.2.3.2 StartResponse
|
|
Properties</h5>
|
|
|
|
<ul>
|
|
<li><code>RequestID</code>. See <a href="#RequestIDField"><b>6.1.4
|
|
RequestID</b></a>. This <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> match the RequestID in the StartRequest
|
|
event.</li>
|
|
|
|
<li><code>Context</code> See <a href="#ContextField"><b>6.1.1
|
|
Context</b></a>. This <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> match the value in the StartRequest
|
|
event.</li>
|
|
|
|
<li><code>Status</code> See <a href="#StatusField"><b>6.1.5
|
|
Status</b></a>.</li>
|
|
|
|
<li><code>StatusInfo</code> Optional. See <a
|
|
href="#StatusInfoField"><b>6.1.6 StatusInfo</b></a>.</li>
|
|
|
|
<li><code>Source</code> See <a href="#SourceField"><b>6.1.2
|
|
Source</b></a>.</li>
|
|
|
|
<li><code>Target</code> See <a href="#TargetField"><b>6.1.3
|
|
Target</b></a>.</li>
|
|
|
|
<li><code>Data</code> Optional. See <a href="#DataField"><b>6.1.7
|
|
Data</b></a>.</li>
|
|
|
|
<li><code>Confidential</code> Optional. See <a
|
|
href="#ConfidentialField"><b>6.1.8 Confidential</b></a>.</li>
|
|
</ul>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a name="d3e1089" id="d3e1089" />6.2.4 DoneNotification</h4>
|
|
|
|
<p>If the Modality Component reaches the end of its processing, it
|
|
<em title="MUST in RFC2119 context" class="RFC2119">MUST</em>
|
|
return a DoneNotification to the IM.</p>
|
|
|
|
<div class="div4">
|
|
<h5><a name="d3e1097" id="d3e1097" />6.2.4.1 DoneNotification
|
|
Properties</h5>
|
|
|
|
<ul>
|
|
<li><code>RequestID</code>. See <a href="#RequestIDField"><b>6.1.4
|
|
RequestID</b></a>. This <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> match the RequestID of the StartRequest
|
|
event.</li>
|
|
|
|
<li><code>Context</code> See <a href="#ContextField"><b>6.1.1
|
|
Context</b></a>. This <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> match the value in the StartRequest
|
|
event.</li>
|
|
|
|
<li><code>Status</code> See <a href="#StatusField"><b>6.1.5
|
|
Status</b></a>.</li>
|
|
|
|
<li><code>StatusInfo</code> Optional. See <a
|
|
href="#StatusInfoField"><b>6.1.6 StatusInfo</b></a>.</li>
|
|
|
|
<li><code>Source</code> See <a href="#SourceField"><b>6.1.2
|
|
Source</b></a>.</li>
|
|
|
|
<li><code>Target</code> See <a href="#TargetField"><b>6.1.3
|
|
Target</b></a>.</li>
|
|
|
|
<li><code>Data</code> Optional. See <a href="#DataField"><b>6.1.7
|
|
Data</b></a>.</li>
|
|
|
|
<li><code>Confidential</code> Optional. See <a
|
|
href="#ConfidentialField"><b>6.1.8 Confidential</b></a>.</li>
|
|
</ul>
|
|
|
|
<p>The DoneNotification event is intended to indicate the
|
|
completion of the processing that has been initiated by the
|
|
Interaction Manager with a StartRequest. As an example a voice
|
|
modality component might use the DoneNotification event to indicate
|
|
the completion of a recognition task. In this case the
|
|
DoneNotification event might carry the recognition result expressed
|
|
using EMMA. However, there may be tasks which do not have a
|
|
specific end. For example the Interaction Manager might send a
|
|
StartRequest to a graphical modality component requesting it to
|
|
display certain information. Such a task does not necessarily have
|
|
a specific end and thus the graphical modality component might
|
|
never send a DoneNotification event to the Interaction Manager.
|
|
Thus the graphical modality component would display the screen
|
|
until it received another StartRequest (or some other lifecycle
|
|
event) from the Interaction Manager.</p>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a name="d3e1157" id="d3e1157" />6.2.5
|
|
CancelRequest/CancelResponse</h4>
|
|
|
|
<p>The IM <em title="MAY in RFC2119 context"
|
|
class="RFC2119">MAY</em> send a CancelRequest to stop processing in
|
|
the Modality Component. In this case, the Modality Component <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> stop
|
|
processing and then <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> return a CancelResponse.</p>
|
|
|
|
<div class="div4">
|
|
<h5><a name="d3e1171" id="d3e1171" />6.2.5.1 CancelRequest
|
|
Properties</h5>
|
|
|
|
<ul>
|
|
<li><code>RequestID</code>. See <a href="#RequestIDField"><b>6.1.4
|
|
RequestID</b></a>. A newly generated identifier used to identify
|
|
this request.</li>
|
|
|
|
<li><code>Context</code> See <a href="#ContextField"><b>6.1.1
|
|
Context</b></a>. This <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> match the value in the StartRequest
|
|
event.</li>
|
|
|
|
<li><code>Source</code> See <a href="#SourceField"><b>6.1.2
|
|
Source</b></a>.</li>
|
|
|
|
<li><code>Target</code> See <a href="#TargetField"><b>6.1.3
|
|
Target</b></a>.</li>
|
|
|
|
<li><code>Data</code> Optional. See <a href="#DataField"><b>6.1.7
|
|
Data</b></a>.</li>
|
|
|
|
<li><code>Confidential</code> Optional. See <a
|
|
href="#ConfidentialField"><b>6.1.8 Confidential</b></a>.</li>
|
|
</ul>
|
|
</div>
|
|
|
|
<div class="div4">
|
|
<h5><a name="d3e1214" id="d3e1214" />6.2.5.2 CancelResponse
|
|
Properties</h5>
|
|
|
|
<ul>
|
|
<li><code>RequestID</code>. See <a href="#RequestIDField"><b>6.1.4
|
|
RequestID</b></a>. This <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> match the RequestID in the CancelRequest
|
|
event.</li>
|
|
|
|
<li><code>Context</code> See <a href="#ContextField"><b>6.1.1
|
|
Context</b></a>. This <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> match the value in the StartRequest
|
|
event.</li>
|
|
|
|
<li><code>Status</code> See <a href="#StatusField"><b>6.1.5
|
|
Status</b></a>.</li>
|
|
|
|
<li><code>StatusInfo</code> Optional. See <a
|
|
href="#StatusInfoField"><b>6.1.6 StatusInfo</b></a>.</li>
|
|
|
|
<li><code>Source</code> See <a href="#SourceField"><b>6.1.2
|
|
Source</b></a>.</li>
|
|
|
|
<li><code>Target</code> See <a href="#TargetField"><b>6.1.3
|
|
Target</b></a>.</li>
|
|
|
|
<li><code>Data</code> Optional. See <a href="#DataField"><b>6.1.7
|
|
Data</b></a>.</li>
|
|
|
|
<li><code>Confidential</code> Optional. See <a
|
|
href="#ConfidentialField"><b>6.1.8 Confidential</b></a>.</li>
|
|
</ul>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a name="d3e1272" id="d3e1272" />6.2.6
|
|
PauseRequest/PauseResponse</h4>
|
|
|
|
<p>The IM <em title="MAY in RFC2119 context"
|
|
class="RFC2119">MAY</em> send a PauseRequest to suspend processing
|
|
by the Modality Component. Modality Components <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> return a
|
|
PauseResponse once they have paused, or once they determine that
|
|
they will be unable to pause.</p>
|
|
|
|
<div class="div4">
|
|
<h5><a name="d3e1283" id="d3e1283" />6.2.6.1 PauseRequest
|
|
Properties</h5>
|
|
|
|
<ul>
|
|
<li><code>RequestID</code>. See <a href="#RequestIDField"><b>6.1.4
|
|
RequestID</b></a>. A newly generated identifier used to identify
|
|
this request.</li>
|
|
|
|
<li><code>Context</code> See <a href="#ContextField"><b>6.1.1
|
|
Context</b></a>. This <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> match the value in the StartRequest
|
|
event.</li>
|
|
|
|
<li><code>Source</code> See <a href="#SourceField"><b>6.1.2
|
|
Source</b></a>.</li>
|
|
|
|
<li><code>Target</code> See <a href="#TargetField"><b>6.1.3
|
|
Target</b></a>.</li>
|
|
|
|
<li><code>Data</code> Optional. See <a href="#DataField"><b>6.1.7
|
|
Data</b></a>.</li>
|
|
|
|
<li><code>Confidential</code> Optional. See <a
|
|
href="#ConfidentialField"><b>6.1.8 Confidential</b></a>.</li>
|
|
</ul>
|
|
</div>
|
|
|
|
<div class="div4">
|
|
<h5><a name="d3e1326" id="d3e1326" />6.2.6.2 PauseResponse
|
|
Properties</h5>
|
|
|
|
<ul>
|
|
<li><code>RequestID</code>. See <a href="#RequestIDField"><b>6.1.4
|
|
RequestID</b></a>. This <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> match the RequestID in the PauseRequest
|
|
event.</li>
|
|
|
|
<li><code>Context</code> See <a href="#ContextField"><b>6.1.1
|
|
Context</b></a>. This <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> match the value in the StartRequest
|
|
event.</li>
|
|
|
|
<li><code>Status</code> See <a href="#StatusField"><b>6.1.5
|
|
Status</b></a>.</li>
|
|
|
|
<li><code>StatusInfo</code> Optional. See <a
|
|
href="#StatusInfoField"><b>6.1.6 StatusInfo</b></a>.</li>
|
|
|
|
<li><code>Source</code> See <a href="#SourceField"><b>6.1.2
|
|
Source</b></a>.</li>
|
|
|
|
<li><code>Target</code> See <a href="#TargetField"><b>6.1.3
|
|
Target</b></a>.</li>
|
|
|
|
<li><code>Data</code> Optional. See <a href="#DataField"><b>6.1.7
|
|
Data</b></a>.</li>
|
|
|
|
<li><code>Confidential</code> Optional. See <a
|
|
href="#ConfidentialField"><b>6.1.8 Confidential</b></a>.</li>
|
|
</ul>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a name="d3e1384" id="d3e1384" />6.2.7
|
|
ResumeRequest/ResumeResponse</h4>
|
|
|
|
<p>The IM <em title="MAY in RFC2119 context"
|
|
class="RFC2119">MAY</em> send the ResumeRequest to resume
|
|
processing that was paused by a previous PauseRequest. The IM <em
|
|
title="MUST NOT in RFC2119 context" class="RFC2119">MUST NOT</em>
|
|
send the ResumeRequest to a context that is not paused due to a
|
|
previous PauseRequest. Implementations that have paused <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> attempt
|
|
to resume processing upon receipt of this event and <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> return a
|
|
ResumeResponse afterwards. The 'Status' <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> be
|
|
'Success' if the implementation has succeeded in resuming
|
|
processing and <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> be 'Failure' otherwise.</p>
|
|
|
|
<div class="div4">
|
|
<h5><a name="d3e1407" id="d3e1407" />6.2.7.1 ResumeRequest
|
|
Properties</h5>
|
|
|
|
<ul>
|
|
<li><code>RequestID</code>. See <a href="#RequestIDField"><b>6.1.4
|
|
RequestID</b></a>. A newly generated identifier used to identify
|
|
this request.</li>
|
|
|
|
<li><code>Context</code> See <a href="#ContextField"><b>6.1.1
|
|
Context</b></a>. This <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> match the value in the StartRequest
|
|
event.</li>
|
|
|
|
<li><code>Source</code> See <a href="#SourceField"><b>6.1.2
|
|
Source</b></a>.</li>
|
|
|
|
<li><code>Target</code> See <a href="#TargetField"><b>6.1.3
|
|
Target</b></a>.</li>
|
|
|
|
<li><code>Data</code> Optional. See <a href="#DataField"><b>6.1.7
|
|
Data</b></a>.</li>
|
|
|
|
<li><code>Confidential</code> Optional. See <a
|
|
href="#ConfidentialField"><b>6.1.8 Confidential</b></a>.</li>
|
|
</ul>
|
|
</div>
|
|
|
|
<div class="div4">
|
|
<h5><a name="d3e1450" id="d3e1450" />6.2.7.2 ResumeResponse
|
|
Properties</h5>
|
|
|
|
<ul>
|
|
<li><code>RequestID</code>. See <a href="#RequestIDField"><b>6.1.4
|
|
RequestID</b></a>. This <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> match the RequestID in the ResumeRequest
|
|
event.</li>
|
|
|
|
<li><code>Context</code> See <a href="#ContextField"><b>6.1.1
|
|
Context</b></a>. This <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> match the value in the StartRequest
|
|
event.</li>
|
|
|
|
<li><code>Status</code> See <a href="#StatusField"><b>6.1.5
|
|
Status</b></a>.</li>
|
|
|
|
<li><code>StatusInfo</code> Optional. See <a
|
|
href="#StatusInfoField"><b>6.1.6 StatusInfo</b></a>.</li>
|
|
|
|
<li><code>Source</code> See <a href="#SourceField"><b>6.1.2
|
|
Source</b></a>.</li>
|
|
|
|
<li><code>Target</code> See <a href="#TargetField"><b>6.1.3
|
|
Target</b></a>.</li>
|
|
|
|
<li><code>Data</code> Optional. See <a href="#DataField"><b>6.1.7
|
|
Data</b></a>.</li>
|
|
|
|
<li><code>Confidential</code> Optional. See <a
|
|
href="#ConfidentialField"><b>6.1.8 Confidential</b></a>.</li>
|
|
</ul>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a name="d3e1508" id="d3e1508" />6.2.8
|
|
ExtensionNotification</h4>
|
|
|
|
<p>This event <em title="MAY in RFC2119 context"
|
|
class="RFC2119">MAY</em> be generated by the IM and <em
|
|
title="MAY in RFC2119 context" class="RFC2119">MAY</em> be
|
|
generated by the Modality Component. It is used to encapsulate
|
|
application-specific events that are extensions to the framework
|
|
defined here. For example, if an application containing a voice
|
|
modality wanted that modality component to notify the Interaction
|
|
Manager when speech was detected, it would cause the voice modality
|
|
to generate an ExtensionNotification event ( with a 'name' of
|
|
something like 'speechDetected') at the appropriate time.</p>
|
|
|
|
<div class="div4">
|
|
<h5><a name="d3e1519" id="d3e1519" />6.2.8.1 ExtensionNotification
|
|
Properties</h5>
|
|
|
|
<ul>
|
|
<li><code>RequestID</code>. See <a href="#RequestIDField"><b>6.1.4
|
|
RequestID</b></a>. A newly generated identifier used to identify
|
|
this request.</li>
|
|
|
|
<li><code>Name</code>The name of the application-specific
|
|
event.</li>
|
|
|
|
<li><code>Context</code> See <a href="#ContextField"><b>6.1.1
|
|
Context</b></a>. <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> match the value in the StartRequest
|
|
event.</li>
|
|
|
|
<li><code>Source</code> See <a href="#SourceField"><b>6.1.2
|
|
Source</b></a>.</li>
|
|
|
|
<li><code>Target</code> See <a href="#TargetField"><b>6.1.3
|
|
Target</b></a>.</li>
|
|
|
|
<li><code>Data</code> Optional. See <a href="#DataField"><b>6.1.7
|
|
Data</b></a>.</li>
|
|
|
|
<li><code>Confidential</code> Optional. See <a
|
|
href="#ConfidentialField"><b>6.1.8 Confidential</b></a>.</li>
|
|
</ul>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a name="d3e1566" id="d3e1566" />6.2.9
|
|
ClearContextRequest/ClearContextResponse</h4>
|
|
|
|
<p>The IM <em title="MAY in RFC2119 context"
|
|
class="RFC2119">MAY</em> send a ClearContextRequest to indicate
|
|
that the specified context is no longer active and that any
|
|
resources associated with it may be freed. Modality Components are
|
|
not required to take any particular action in response to this
|
|
command, but <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> return a ClearContextResponse. Once the
|
|
IM has sent a ClearContextRequest to a Modality Component, it <em
|
|
title="MUST NOT in RFC2119 context" class="RFC2119">MUST NOT</em>
|
|
send the Modality Component any more events for that context.</p>
|
|
|
|
<div class="div4">
|
|
<h5><a name="d3e1580" id="d3e1580" />6.2.9.1 ClearContextRequest
|
|
Properties</h5>
|
|
|
|
<ul>
|
|
<li><code>RequestID</code>. See <a href="#RequestIDField"><b>6.1.4
|
|
RequestID</b></a>. A newly generated identifier used to identify
|
|
this request.</li>
|
|
|
|
<li><code>Context</code> See <a href="#ContextField"><b>6.1.1
|
|
Context</b></a>. This <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> match the value in the StartRequest
|
|
event.</li>
|
|
|
|
<li><code>Source</code> See <a href="#SourceField"><b>6.1.2
|
|
Source</b></a>.</li>
|
|
|
|
<li><code>Target</code> See <a href="#TargetField"><b>6.1.3
|
|
Target</b></a>.</li>
|
|
|
|
<li><code>Data</code> Optional. See <a href="#DataField"><b>6.1.7
|
|
Data</b></a>.</li>
|
|
|
|
<li><code>Confidential</code> Optional. See <a
|
|
href="#ConfidentialField"><b>6.1.8 Confidential</b></a>.</li>
|
|
</ul>
|
|
</div>
|
|
|
|
<div class="div4">
|
|
<h5><a name="d3e1623" id="d3e1623" />6.2.9.2 ClearContextResponse
|
|
Properties</h5>
|
|
|
|
<ul>
|
|
<li><code>RequestID</code>. See <a href="#RequestIDField"><b>6.1.4
|
|
RequestID</b></a>. This <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> match the RequestID in the
|
|
ClearContextRequest event.</li>
|
|
|
|
<li><code>Context</code> See <a href="#ContextField"><b>6.1.1
|
|
Context</b></a>. This <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> match the value in the StartRequest
|
|
event.</li>
|
|
|
|
<li><code>Status</code> See <a href="#StatusField"><b>6.1.5
|
|
Status</b></a>.</li>
|
|
|
|
<li><code>StatusInfo</code> Optional. See <a
|
|
href="#StatusInfoField"><b>6.1.6 StatusInfo</b></a>.</li>
|
|
|
|
<li><code>Source</code> See <a href="#SourceField"><b>6.1.2
|
|
Source</b></a>.</li>
|
|
|
|
<li><code>Target</code> See <a href="#TargetField"><b>6.1.3
|
|
Target</b></a>.</li>
|
|
|
|
<li><code>Data</code> Optional. See <a href="#DataField"><b>6.1.7
|
|
Data</b></a>.</li>
|
|
|
|
<li><code>Confidential</code> Optional. See <a
|
|
href="#ConfidentialField"><b>6.1.8 Confidential</b></a>.</li>
|
|
</ul>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a name="d3e1681" id="d3e1681" />6.2.10
|
|
StatusRequest/StatusResponse</h4>
|
|
|
|
<p>The StatusRequest message and the corresponding StatusResponse
|
|
are intended to provide keep-alive functionality. Either the IM or
|
|
the Modality Component <em title="MAY in RFC2119 context"
|
|
class="RFC2119">MAY</em> send the StatusRequest message. The
|
|
recipient <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> respond with the StatusResponse
|
|
message.</p>
|
|
|
|
<div class="div4">
|
|
<h5><a name="d3e1692" id="d3e1692" />6.2.10.1 Status Request
|
|
Properties</h5>
|
|
|
|
<ul>
|
|
<li><code>RequestID</code>. See <a href="#RequestIDField"><b>6.1.4
|
|
RequestID</b></a>. A newly generated identifier used to identify
|
|
this request.</li>
|
|
|
|
<li><code>Context</code> See <a href="#ContextField"><b>6.1.1
|
|
Context</b></a>. Optional specification of the context for which
|
|
the status is requested. If it is present, the recipient <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> respond
|
|
with a StatusResponse message indicating the status of the
|
|
specified context. If it is not present, the recipient <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> send a
|
|
StatusResponse message indicating the status of the underlying
|
|
server, namely the software that would host a new context if one
|
|
were created.</li>
|
|
|
|
<li><code>RequestAutomaticUpdate</code>. A boolean value. If it is
|
|
'true' the recipient <em title="SHOULD in RFC2119 context"
|
|
class="RFC2119">SHOULD</em> send periodic StatusResponse messages
|
|
without waiting for an additional StatusRequest message. If it is
|
|
'false', the recipient <em title="SHOULD in RFC2119 context"
|
|
class="RFC2119">SHOULD</em> send one and only one StatusResponse
|
|
message in response to this request.</li>
|
|
|
|
<li><code>Source</code> See <a href="#SourceField"><b>6.1.2
|
|
Source</b></a>.</li>
|
|
|
|
<li><code>Target</code> See <a href="#TargetField"><b>6.1.3
|
|
Target</b></a>.</li>
|
|
|
|
<li><code>Data</code> Optional. See <a href="#DataField"><b>6.1.7
|
|
Data</b></a>.</li>
|
|
|
|
<li><code>Confidential</code> Optional. See <a
|
|
href="#ConfidentialField"><b>6.1.8 Confidential</b></a>.</li>
|
|
</ul>
|
|
</div>
|
|
|
|
<div class="div4">
|
|
<h5><a name="d3e1748" id="d3e1748" />6.2.10.2 StatusResponse
|
|
Properties</h5>
|
|
|
|
<ul>
|
|
<li><code>RequestID</code>. See <a href="#RequestIDField"><b>6.1.4
|
|
RequestID</b></a>. This <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> match the RequestID in the StatusRequest
|
|
event.</li>
|
|
|
|
<li><code>AutomaticUpdate</code>. A boolean value. If it is 'true'
|
|
the sender <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> keep sending StatusResponse messages in
|
|
the future without waiting for another StatusRequest message. If it
|
|
is 'false', the sender <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> wait for a subsequent StatusRequest
|
|
message before sending another StatusResponse message.</li>
|
|
|
|
<li><code>Context</code> See <a href="#ContextField"><b>6.1.1
|
|
Context</b></a>. An optional specification of the context for which
|
|
the status is being returned. If it is present, the response <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> represent
|
|
the status of the specified context. If it is not present, the
|
|
response <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> represent the status of the underlying
|
|
server.</li>
|
|
|
|
<li><code>Status</code> An enumeration of 'Alive' or 'Dead'. The
|
|
meaning of these values depends on whether the 'context' parameter
|
|
is present. If it is, and the specified context is still active and
|
|
capable of handling new life cycle events, the sender <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> set this
|
|
field to 'Alive'. If the 'context' parameter is present and the
|
|
context has terminated or is otherwise unable to process new life
|
|
cycle events, the sender <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> set the status to 'Dead'. If the
|
|
'context' parameter is not provided, the status refers to the
|
|
underlying server. If the sender is able to create new contexts, it
|
|
<em title="MUST in RFC2119 context" class="RFC2119">MUST</em> set
|
|
the status to 'Alive', otherwise, it <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> set it to
|
|
'Dead'.</li>
|
|
|
|
<li><code>Source</code> See <a href="#SourceField"><b>6.1.2
|
|
Source</b></a>.</li>
|
|
|
|
<li><code>Target</code> See <a href="#TargetField"><b>6.1.3
|
|
Target</b></a>.</li>
|
|
|
|
<li><code>Data</code> Optional. See <a href="#DataField"><b>6.1.7
|
|
Data</b></a>.</li>
|
|
|
|
<li><code>Confidential</code> Optional. See <a
|
|
href="#ConfidentialField"><b>6.1.8 Confidential</b></a>.</li>
|
|
</ul>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="back">
|
|
<div class="div1">
|
|
<h2><a name="d3e1824" id="d3e1824" />A Modality Component
|
|
States</h2>
|
|
|
|
[This section is informative]
|
|
|
|
<p>Within an established context, a Modality Component can be
|
|
viewed as functioning in one of three states: Idle, Running or
|
|
Paused. Lifecycle events received from the Interaction Manager
|
|
imply specific actions and transitions between states. The table
|
|
below shows possible MC actions, state transitions and response
|
|
contents for each Request event the IM may send to a MC in a
|
|
particular state.</p>
|
|
|
|
<p>A <em>Failure: ErrorMessage</em> annotation indicates that the
|
|
specified Request event is either invalid or redundant in the
|
|
specified state. In this case, the Modality Component responds by
|
|
sending a matching Response event with Status=Failure and
|
|
StatusInfo=ErrorMessage. In all other cases, the Modality performs
|
|
the requested action, possibly transitioning to another state as
|
|
indicated.</p>
|
|
|
|
<table border="1">
|
|
<tbody>
|
|
<tr>
|
|
<th width="25%">event / state</th>
|
|
<th width="25%">Idle</th>
|
|
<th width="25%">Running</th>
|
|
<th width="25%">Paused</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>PrepareRequest</td>
|
|
<td>preload or update content</td>
|
|
<td>preload or update content</td>
|
|
<td>preload or update content</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td rowspan="2">StartRequest</td>
|
|
<td><em>Transition: Running</em>
|
|
<p>use new content if provided, otherwise use last available
|
|
content</p>
|
|
</td>
|
|
<td rowspan="2">stop processing current content, restart as in
|
|
Idle</td>
|
|
<td rowspan="2"><em>Transition: Running</em>
|
|
<p>stop processing current content, restart as in Idle</p>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><em>Failure: NoContent</em> if MC requires content to run and
|
|
none has been provided</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>CancelRequest</td>
|
|
<td><em>Ignore</em></td>
|
|
<td><em>Transition: Idle</em></td>
|
|
<td><em>Transition: Idle</em></td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td rowspan="2">PauseRequest</td>
|
|
<td rowspan="2"><em>Failure: ignore</em></td>
|
|
<td><em>Transition: Paused</em></td>
|
|
<td rowspan="2"><em>Ignore</em></td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><em>Failure: CantPause</em> if MC is unable to pause</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>ResumeRequest</td>
|
|
<td><em>Ignore</em></td>
|
|
<td><em>Failure: AlreadyRunning</em></td>
|
|
<td><em>Transition: Running</em></td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>StatusRequest</td>
|
|
<td>send status</td>
|
|
<td>send status</td>
|
|
<td>send status</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>ClearContextRequest</td>
|
|
<td><em>close session</em></td>
|
|
<td><em>close session</em></td>
|
|
<td><em>close session</em></td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<p>Here is a state chart representation of these transitions:</p>
|
|
|
|
<img class="center" src="Images/MC_state_diagram.png"
|
|
alt="architecture diagram" /></div>
|
|
|
|
<div class="div1">
|
|
<h2><a name="EventExamples" id="EventExamples" />B Examples of
|
|
Life-Cycle Events</h2>
|
|
|
|
[This section is informative]
|
|
|
|
<div class="div2">
|
|
<h3><a name="d3e1945" id="d3e1945" />B.1 NewContextRequest (from MC
|
|
to IM)</h3>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0">
|
|
<mmi:newContextRequest mmi:source="someURI"
|
|
mmi:target="someOtherURI" mmi:requestID="request-1">
|
|
</mmi:newContextRequest>
|
|
</mmi:mmi>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a name="d3e1950" id="d3e1950" />B.2 NewContextResponse (from
|
|
IM to MC)</h3>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0">
|
|
<mmi:newContextResponse mmi:source="someURI" mmi:target="someOtherURI"
|
|
mmi:requestID="request-1" mmi:status="success" mmi:context="URI-1">
|
|
</mmi:newContextResponse>
|
|
</mmi:mmi>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a name="d3e1955" id="d3e1955" />B.3 PrepareRequest (from IM to
|
|
MC, with external markup)</h3>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0">
|
|
<mmi:prepareRequest mmi:source="someURI" mmi:target="someOtherURI"
|
|
mmi:context="URI-1" mmi:requestID="request-1">
|
|
<mmi:contentURL mmi:href="someContentURI" mmi:max-age="" mmi:fetchtimeout="1s"/>
|
|
</mmi:prepareRequest>
|
|
</mmi:mmi>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a name="d3e1960" id="d3e1960" />B.4 PrepareRequest (from IM to
|
|
MC, inline VoiceXML markup)</h3>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0"
|
|
xmlns:vxml="http://www.w3.org/2001/vxml">
|
|
<mmi:prepareRequest mmi:source="someURI" mmi:target="someOtherURI"
|
|
mmi:context="URI-1" mmi:requestID="request-1" >
|
|
<mmi:content>
|
|
<vxml:vxml version="2.0">
|
|
<vxml:form>
|
|
<vxml:block>Hello World!</vxml:block>
|
|
</vxml:form>
|
|
</vxml:vxml>
|
|
</mmi:content>
|
|
</mmi:prepareRequest>
|
|
</mmi:mmi>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a name="d3e1965" id="d3e1965" />B.5 PrepareResponse (from MC
|
|
to IM, Success)</h3>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0">
|
|
<mmi:prepareResponse mmi:source="someURI" mmi:target="someOtherURI" mmi:context="someURI"
|
|
mmi:requestID="request-1" mmi:status="success"/>
|
|
</mmi:mmi>
|
|
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a name="d3e1970" id="d3e1970" />B.6 PrepareResponse (from MC
|
|
to IM, Failure)</h3>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0">
|
|
<mmi:prepareResponse mmi:source="someURI" mmi:target="someOtherURI" mmi:context="someURI"
|
|
mmi:requestID="request-1" mmi:status="failure">
|
|
<mmi:statusInfo>
|
|
NotAuthorized
|
|
</mmi:statusInfo>
|
|
</mmi:prepareResponse>
|
|
</mmi:mmi>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a name="d3e1975" id="d3e1975" />B.7 StartRequest (from IM to
|
|
MC)</h3>
|
|
</div>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0">
|
|
<mmi:startRequest mmi:source="someURI" mmi:target="someOtherURI" mmi:context="URI-1" mmi:requestID="request-1">
|
|
<mmi:contentURL mmi:href="someContentURI" mmi:max-age="" mmi:fetchtimeout="1s"/>
|
|
</mmi:startRequest>
|
|
</mmi:mmi>
|
|
</pre>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a name="d3e1980" id="d3e1980" />B.8 StartResponse (from MC to
|
|
IM)</h3>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0">
|
|
<mmi:startResponse mmi:source="someURI" mmi:target="someOtherURI" mmi:context="someURI" mmi:requestID="request-1"
|
|
mmi:status="failure">
|
|
<mmi:statusInfo>
|
|
NotAuthorized
|
|
</mmi:statusInfo>
|
|
</mmi:startResponse>
|
|
</mmi:mmi>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a name="d3e1985" id="d3e1985" />B.9 DoneNotification (from MC
|
|
to IM, with EMMA result)</h3>
|
|
|
|
<p>This requestID corresponds to the requestID of the
|
|
"StartRequest" event that started it.</p>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0"
|
|
xmlns:emma="http://www.w3.org/2003/04/emma">
|
|
<mmi:doneNotification mmi:source="someURI" mmi:target="someOtherURI" mmi:context="someURI"
|
|
mmi:status="success" mmi:requestID="request-1" mmi:confidential="true">
|
|
<mmi:data>
|
|
<emma:emma version="1.0">
|
|
<emma:interpretation id="int1" emma:medium="acoustic" emma:confidence=".75"
|
|
emma:mode="voice" emma:tokens="flights from boston to denver">
|
|
<origin>Boston</origin>
|
|
<destination>Denver</destination>
|
|
</emma:interpretation>
|
|
</emma:emma>
|
|
</mmi:data>
|
|
</mmi:doneNotification>
|
|
</mmi:mmi>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a name="d3e1992" id="d3e1992" />B.10 DoneNotification (from MC
|
|
to IM, with EMMA "no-input" result)</h3>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0"
|
|
xmlns:emma="http://www.w3.org/2003/04/emma">
|
|
<mmi:doneNotification mmi:source="someURI" mmi:target="someOtherURI" mmi:context="someURI"
|
|
mmi:status="success" mmi:requestID="request-1" >
|
|
<mmi:data>
|
|
<emma:emma version="1.0">
|
|
<emma:interpretation id="int1" emma:no-input="true"/>
|
|
</emma:emma>
|
|
</mmi:data>
|
|
</mmi:doneNotification>
|
|
</mmi:mmi>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a name="d3e1997" id="d3e1997" />B.11 CancelRequest (from IM to
|
|
MC)</h3>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0">
|
|
<mmi:cancelRequest mmi:source="someURI" mmi:target="someOtherURI" mmi:context="someURI"
|
|
mmi:requestID="request-1"/>
|
|
</mmi:mmi>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a name="d3e2002" id="d3e2002" />B.12 CancelResponse (from MC
|
|
to IM)</h3>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0">
|
|
<mmi:cancelResponse mmi:source="someURI" mmi:target="someOtherURI" mmi:context="someURI" mmi:requestID="request-1"
|
|
mmi:status="success"/>
|
|
</mmi:mmi>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a name="d3e2007" id="d3e2007" />B.13 PauseRequest (from IM to
|
|
MC)</h3>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0">
|
|
<mmi:pauseRequest mmi:context="someURI" mmi:source="someURI" mmi:target="someOtherURI"
|
|
mmi:requestID="request-1"/>
|
|
</mmi:mmi>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a name="d3e2012" id="d3e2012" />B.14 PauseResponse (from MC to
|
|
IM)</h3>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0">
|
|
<mmi:pauseResponse mmi:source="someURI" mmi:target="someOtherURI" mmi:context="someURI" mmi:requestID="request-1"
|
|
mmi:status="success"/>
|
|
</mmi:mmi>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a name="d3e2017" id="d3e2017" />B.15 ResumeRequest (from IM to
|
|
MC)</h3>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0">
|
|
<mmi:resumeRequest mmi:context="someURI" mmi:source="someURI" mmi:target="someOtherURI"
|
|
mmi:requestID="request-1"/>
|
|
</mmi:mmi>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a name="d3e2022" id="d3e2022" />B.16 ResumeResponse (from MC
|
|
to IM)</h3>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0">
|
|
<mmi:resumeResponse mmi:source="someURI" mmi:target="someOtherURI" mmi:context="someURI" mmi:requestID="request-1"
|
|
mmi:status="success"/>
|
|
</mmi:mmi>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a name="d3e2027" id="d3e2027" />B.17 ExtensionNotification
|
|
(formerly the data event, sent in both directions)</h3>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0">
|
|
<mmi:extensionNotification mmi:name="appEvent" mmi:source="someURI"
|
|
mmi:target="someOtherURI" mmi:context="someURI" mmi:requestID="request-1">
|
|
</mmi:extensionNotification>
|
|
</mmi:mmi>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a name="d3e2032" id="d3e2032" />B.18 ClearContextRequest (from
|
|
the IM to MC)</h3>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0">
|
|
<mmi:clearContextRequest mmi:source="someURI" mmi:target="someOtherURI" mmi:context="someURI"
|
|
mmi:requestID="request-2"/>
|
|
</mmi:mmi>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a name="d3e2037" id="d3e2037" />B.19 ClearContextResponse
|
|
(from the MC to IM)</h3>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0">
|
|
<mmi:clearContextResponse mmi:source="someURI" mmi:target="someOtherURI" mmi:context="someURI"
|
|
mmi:requestID="request-2" mmi:status="success"/>
|
|
</mmi:mmi>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a name="d3e2042" id="d3e2042" />B.20 StatusRequest (from the
|
|
IM to the MC)</h3>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0">
|
|
<mmi:statusRequest mmi:requestAutomaticUpdate="true" mmi:source="someURI"
|
|
mmi:target="someOtherURI" mmi:requestID="request-3" mmi:context="aToken"/>
|
|
</mmi:mmi>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a name="d3e2047" id="d3e2047" />B.21 StatusResponse (from the
|
|
MC to the IM)</h3>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0">
|
|
<mmi:statusResponse mmi:automaticUpdate="true" mmi:status="alive"
|
|
mmi:source="someURI" mmi:target="someOtherURI" mmi:requestID="request-3" mmi:context="aToken"/>
|
|
</mmi:mmi>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div1">
|
|
<h2><a name="Schema" id="Schema" />C Event Schemas</h2>
|
|
|
|
<p>This specification does not require any particular transport
|
|
format for life cycle events, however in the case where XML is
|
|
used, the following schemas are normative.</p>
|
|
|
|
<div class="div2">
|
|
<h3><a name="d3e2057" id="d3e2057" />C.1 mmi.xsd</h3>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
|
<xs:schema xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" xmlns:xs="http://www.w3.org/2001/XMLSchema" attributeFormDefault="qualified" elementFormDefault="qualified" targetNamespace="http://www.w3.org/2008/04/mmi-arch">
|
|
<xs:annotation>
|
|
<xs:documentation xml:lang="en">
|
|
Schema definition for MMI Life cycle events version 1.0
|
|
</xs:documentation>
|
|
</xs:annotation>
|
|
<xs:include schemaLocation="mmi-attribs.xsd"/>
|
|
<xs:include schemaLocation="NewContextRequest.xsd"/>
|
|
<xs:include schemaLocation="NewContextResponse.xsd"/>
|
|
<xs:include schemaLocation="ClearContextRequest.xsd"/>
|
|
<xs:include schemaLocation="ClearContextResponse.xsd"/>
|
|
<xs:include schemaLocation="CancelRequest.xsd"/>
|
|
<xs:include schemaLocation="CancelResponse.xsd"/>
|
|
<xs:include schemaLocation="DoneNotification.xsd"/>
|
|
<xs:include schemaLocation="ExtensionNotification.xsd"/>
|
|
<xs:include schemaLocation="PauseRequest.xsd"/>
|
|
<xs:include schemaLocation="PauseResponse.xsd"/>
|
|
<xs:include schemaLocation="PrepareRequest.xsd"/>
|
|
<xs:include schemaLocation="PrepareResponse.xsd"/>
|
|
<xs:include schemaLocation="ResumeRequest.xsd"/>
|
|
<xs:include schemaLocation="ResumeResponse.xsd"/>
|
|
<xs:include schemaLocation="StartRequest.xsd"/>
|
|
<xs:include schemaLocation="StartResponse.xsd"/>
|
|
<xs:include schemaLocation="StatusRequest.xsd"/>
|
|
<xs:include schemaLocation="StatusResponse.xsd"/>
|
|
<xs:element name="mmi">
|
|
<xs:complexType>
|
|
<xs:choice>
|
|
<xs:sequence>
|
|
<xs:element ref="mmi:NewContextRequest"/>
|
|
</xs:sequence>
|
|
<xs:sequence>
|
|
<xs:element ref="mmi:NewContextResponse"/>
|
|
</xs:sequence>
|
|
<xs:sequence>
|
|
<xs:element ref="mmi:ClearContextRequest"/>
|
|
</xs:sequence>
|
|
<xs:sequence>
|
|
<xs:element ref="mmi:ClearContextResponse"/>
|
|
</xs:sequence>
|
|
<xs:sequence>
|
|
<xs:element ref="mmi:CancelRequest"/>
|
|
</xs:sequence>
|
|
<xs:sequence>
|
|
<xs:element ref="mmi:CancelResponse"/>
|
|
</xs:sequence>
|
|
<xs:sequence>
|
|
<xs:element ref="mmi:DoneNotification"/>
|
|
</xs:sequence>
|
|
<xs:sequence>
|
|
<xs:element ref="mmi:ExtensionNotification"/>
|
|
</xs:sequence>
|
|
<xs:sequence>
|
|
<xs:element ref="mmi:PauseRequest"/>
|
|
</xs:sequence>
|
|
<xs:sequence>
|
|
<xs:element ref="mmi:PauseResponse"/>
|
|
</xs:sequence>
|
|
<xs:sequence>
|
|
<xs:element ref="mmi:PrepareRequest"/>
|
|
</xs:sequence>
|
|
<xs:sequence>
|
|
<xs:element ref="mmi:PrepareResponse"/>
|
|
</xs:sequence>
|
|
<xs:sequence>
|
|
<xs:element ref="mmi:ResumeRequest"/>
|
|
</xs:sequence>
|
|
<xs:sequence>
|
|
<xs:element ref="mmi:ResumeResponse"/>
|
|
</xs:sequence>
|
|
<xs:sequence>
|
|
<xs:element ref="mmi:StartRequest"/>
|
|
</xs:sequence>
|
|
<xs:sequence>
|
|
<xs:element ref="mmi:StartResponse"/>
|
|
</xs:sequence>
|
|
<xs:sequence>
|
|
<xs:element ref="mmi:StatusRequest"/>
|
|
</xs:sequence>
|
|
<xs:sequence>
|
|
<xs:element ref="mmi:StatusResponse"/>
|
|
</xs:sequence>
|
|
</xs:choice>
|
|
<xs:attribute form="unqualified" name="version" type="xs:decimal" use="required"/>
|
|
</xs:complexType>
|
|
</xs:element>
|
|
</xs:schema>
|
|
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a name="d3e2062" id="d3e2062" />C.2 mmi-datatypes.xsd</h3>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
|
<xs:schema xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" xmlns:xs="http://www.w3.org/2001/XMLSchema" attributeFormDefault="qualified" targetNamespace="http://www.w3.org/2008/04/mmi-arch">
|
|
<xs:annotation>
|
|
<xs:documentation xml:lang="en">
|
|
general Type definition schema for MMI Life cycle events version 1.0
|
|
</xs:documentation>
|
|
</xs:annotation>
|
|
<xs:include schemaLocation="mmi-attribs.xsd"/>
|
|
<xs:simpleType name="targetType">
|
|
<xs:restriction base="xs:string"/>
|
|
</xs:simpleType>
|
|
<xs:simpleType name="requestIDType">
|
|
<xs:restriction base="xs:string"/>
|
|
</xs:simpleType>
|
|
<xs:simpleType name="contextType">
|
|
<xs:restriction base="xs:string"/>
|
|
</xs:simpleType>
|
|
<xs:simpleType name="statusType">
|
|
<xs:restriction base="xs:string">
|
|
<xs:enumeration value="success"/>
|
|
<xs:enumeration value="failure"/>
|
|
</xs:restriction>
|
|
</xs:simpleType>
|
|
<xs:simpleType name="statusResponseType">
|
|
<xs:restriction base="xs:string">
|
|
<xs:enumeration value="alive"/>
|
|
<xs:enumeration value="dead"/>
|
|
</xs:restriction>
|
|
</xs:simpleType>
|
|
<xs:complexType name="contentURLType">
|
|
<xs:attribute name="href" type="xs:anyURI" use="required"/>
|
|
<xs:attribute name="max-age" type="xs:string" use="optional"/>
|
|
<xs:attribute name="fetchtimeout" type="xs:string" use="optional"/>
|
|
</xs:complexType>
|
|
<xs:complexType name="contentType">
|
|
<xs:sequence>
|
|
<xs:any maxOccurs="unbounded" namespace="http://www.w3.org/2001/vxml" processContents="skip"/>
|
|
</xs:sequence>
|
|
</xs:complexType>
|
|
<xs:complexType name="emmaType">
|
|
<xs:sequence>
|
|
<xs:any maxOccurs="unbounded" namespace="http://www.w3.org/2003/04/emma" processContents="skip"/>
|
|
</xs:sequence>
|
|
</xs:complexType>
|
|
<xs:complexType mixed="true" name="anyComplexType">
|
|
<xs:complexContent mixed="true">
|
|
<xs:restriction base="xs:anyType">
|
|
<xs:sequence>
|
|
<xs:any maxOccurs="unbounded" minOccurs="0" processContents="skip"/>
|
|
</xs:sequence>
|
|
</xs:restriction>
|
|
</xs:complexContent>
|
|
</xs:complexType>
|
|
</xs:schema>
|
|
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a name="d3e2067" id="d3e2067" />C.3 mmi-attribs.xsd</h3>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
|
<xs:schema xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" xmlns:xs="http://www.w3.org/2001/XMLSchema" attributeFormDefault="qualified" targetNamespace="http://www.w3.org/2008/04/mmi-arch">
|
|
<xs:annotation>
|
|
<xs:documentation xml:lang="en">
|
|
general Type definition schema for MMI Life cycle events version 1.0
|
|
</xs:documentation>
|
|
</xs:annotation>
|
|
<xs:include schemaLocation="mmi-datatypes.xsd"/>
|
|
<xs:attributeGroup name="source.attrib">
|
|
<xs:attribute name="Source" type="xs:string" use="required"/>
|
|
</xs:attributeGroup>
|
|
<xs:attributeGroup name="target.attrib">
|
|
<xs:attribute name="Target" type="mmi:targetType" use="optional"/>
|
|
</xs:attributeGroup>
|
|
<xs:attributeGroup name="requestID.attrib">
|
|
<xs:attribute name="RequestID" type="mmi:requestIDType" use="required"/>
|
|
</xs:attributeGroup>
|
|
<xs:attributeGroup name="context.attrib">
|
|
<xs:attribute name="Context" type="mmi:contextType" use="required"/>
|
|
</xs:attributeGroup>
|
|
<xs:attributeGroup name="confidential.attrib">
|
|
<xs:attribute name="Confidential" type="xs:boolean" use="optional"/>
|
|
</xs:attributeGroup>
|
|
<xs:attributeGroup name="context.optional.attrib">
|
|
<xs:attribute name="Context" type="mmi:contextType" use="optional"/>
|
|
</xs:attributeGroup>
|
|
<xs:attributeGroup name="status.attrib">
|
|
<xs:attribute name="Status" type="mmi:statusType" use="required"/>
|
|
</xs:attributeGroup>
|
|
<xs:attributeGroup name="statusResponse.attrib">
|
|
<xs:attribute name="Status" type="mmi:statusResponseType" use="required"/>
|
|
</xs:attributeGroup>
|
|
<xs:attributeGroup name="extension.name.attrib">
|
|
<xs:attribute name="Name" type="xs:string" use="required"/>
|
|
</xs:attributeGroup>
|
|
<xs:attributeGroup name="requestAutomaticUpdate.attrib">
|
|
<xs:attribute name="RequestAutomaticUpdate" type="xs:boolean" use="required"/>
|
|
</xs:attributeGroup>
|
|
<xs:attributeGroup name="automaticUpdate.attrib">
|
|
<xs:attribute name="AutomaticUpdate" type="xs:boolean" use="required"/>
|
|
</xs:attributeGroup>
|
|
<xs:attributeGroup name="group.allEvents.attrib">
|
|
<xs:attributeGroup ref="mmi:source.attrib"/>
|
|
<xs:attributeGroup ref="mmi:target.attrib"/>
|
|
<xs:attributeGroup ref="mmi:requestID.attrib"/>
|
|
<xs:attributeGroup ref="mmi:context.attrib"/>
|
|
<xs:attributeGroup ref="mmi:confidential.attrib"/>
|
|
</xs:attributeGroup>
|
|
<xs:attributeGroup name="group.allResponseEvents.attrib">
|
|
<xs:attributeGroup ref="mmi:group.allEvents.attrib"/>
|
|
<xs:attributeGroup ref="mmi:status.attrib"/>
|
|
</xs:attributeGroup>
|
|
</xs:schema>
|
|
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a name="d3e2072" id="d3e2072" />C.4 mmi-elements.xsd</h3>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
|
<xs:schema xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" xmlns:xs="http://www.w3.org/2001/XMLSchema" attributeFormDefault="qualified" targetNamespace="http://www.w3.org/2008/04/mmi-arch">
|
|
<xs:annotation>
|
|
<xs:documentation xml:lang="en">
|
|
general elements definition schema for MMI Life cycle events version 1.0
|
|
</xs:documentation>
|
|
</xs:annotation>
|
|
<xs:include schemaLocation="mmi-datatypes.xsd"/>
|
|
|
|
<!-- ELEMENTS -->
|
|
<xs:element name="statusInfo" type="mmi:anyComplexType"/>
|
|
</xs:schema>
|
|
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a name="d3e2077" id="d3e2077" />C.5 NewContextRequest.xsd</h3>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
|
<xs:schema xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" xmlns:xs="http://www.w3.org/2001/XMLSchema" attributeFormDefault="qualified" elementFormDefault="qualified" targetNamespace="http://www.w3.org/2008/04/mmi-arch">
|
|
<xs:annotation>
|
|
<xs:documentation xml:lang="en">
|
|
NewContextRequest schema for MMI Life cycle events version 1.0
|
|
</xs:documentation>
|
|
</xs:annotation>
|
|
<xs:include schemaLocation="mmi-datatypes.xsd"/>
|
|
<xs:include schemaLocation="mmi-attribs.xsd"/>
|
|
<xs:include schemaLocation="mmi-elements.xsd"/>
|
|
|
|
<xs:element name="NewContextRequest">
|
|
<xs:complexType>
|
|
<xs:sequence>
|
|
<xs:element minOccurs="0" name="data" type="mmi:anyComplexType"/>
|
|
</xs:sequence>
|
|
<xs:attributeGroup ref="mmi:source.attrib"/>
|
|
<xs:attributeGroup ref="mmi:target.attrib"/>
|
|
<xs:attributeGroup ref="mmi:requestID.attrib"/>
|
|
</xs:complexType>
|
|
</xs:element>
|
|
</xs:schema>
|
|
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a name="d3e2082" id="d3e2082" />C.6
|
|
NewContextResponse.xsd</h3>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
|
<xs:schema xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" xmlns:xs="http://www.w3.org/2001/XMLSchema" attributeFormDefault="qualified" elementFormDefault="qualified" targetNamespace="http://www.w3.org/2008/04/mmi-arch">
|
|
<xs:annotation>
|
|
<xs:documentation xml:lang="en">
|
|
NewContextResponse schema for MMI Life cycle events version 1.0
|
|
</xs:documentation>
|
|
</xs:annotation>
|
|
<xs:include schemaLocation="mmi-datatypes.xsd"/>
|
|
<xs:include schemaLocation="mmi-attribs.xsd"/>
|
|
<xs:include schemaLocation="mmi-elements.xsd"/>
|
|
|
|
<xs:element name="NewContextResponse">
|
|
<xs:complexType>
|
|
<xs:sequence>
|
|
<xs:element minOccurs="0" ref="mmi:statusInfo"/>
|
|
</xs:sequence>
|
|
<xs:attributeGroup ref="mmi:group.allResponseEvents.attrib"/>
|
|
</xs:complexType>
|
|
</xs:element>
|
|
</xs:schema>
|
|
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a name="d3e2087" id="d3e2087" />C.7 PrepareRequest.xsd</h3>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
|
<xs:schema xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" xmlns:xs="http://www.w3.org/2001/XMLSchema" attributeFormDefault="qualified" elementFormDefault="qualified" targetNamespace="http://www.w3.org/2008/04/mmi-arch">
|
|
<xs:annotation>
|
|
<xs:documentation xml:lang="en">
|
|
PrepareRequest schema for MMI Life cycle events version 1.0.
|
|
The optional PrepareRequest event is an event that the Runtime Framework may send
|
|
to allow the Modality Components to pre-load markup and prepare to run (e.g. in case of
|
|
VXML VUI-MC). Modality Components are not required to take any particular action in
|
|
response to this event, but they must return a PrepareResponse event.
|
|
</xs:documentation>
|
|
</xs:annotation>
|
|
<xs:include schemaLocation="mmi-datatypes.xsd"/>
|
|
<xs:include schemaLocation="mmi-attribs.xsd"/>
|
|
|
|
<xs:element name="PrepareRequest">
|
|
<xs:complexType>
|
|
<xs:choice>
|
|
<xs:sequence>
|
|
<xs:element name="ContentURL" type="mmi:contentURLType"/>
|
|
</xs:sequence>
|
|
<xs:sequence>
|
|
<xs:element name="Content" type="mmi:anyComplexType"/>
|
|
</xs:sequence>
|
|
<xs:sequence>
|
|
<xs:element minOccurs="0" name="Data" type="mmi:anyComplexType"/>
|
|
</xs:sequence>
|
|
</xs:choice>
|
|
<xs:attributeGroup ref="mmi:group.allEvents.attrib"/>
|
|
</xs:complexType>
|
|
</xs:element>
|
|
</xs:schema>
|
|
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a name="d3e2092" id="d3e2092" />C.8 PrepareResponse.xsd</h3>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
|
<xs:schema xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" xmlns:xs="http://www.w3.org/2001/XMLSchema" attributeFormDefault="qualified" elementFormDefault="qualified" targetNamespace="http://www.w3.org/2008/04/mmi-arch">
|
|
<xs:annotation>
|
|
<xs:documentation xml:lang="en">
|
|
PrepareResponse schema for MMI Life cycle events version 1.0
|
|
</xs:documentation>
|
|
</xs:annotation>
|
|
<xs:include schemaLocation="mmi-datatypes.xsd"/>
|
|
<xs:include schemaLocation="mmi-attribs.xsd"/>
|
|
<xs:include schemaLocation="mmi-elements.xsd"/>
|
|
|
|
<xs:element name="PrepareResponse">
|
|
<xs:complexType>
|
|
<xs:sequence>
|
|
<xs:element minOccurs="0" name="data" type="mmi:anyComplexType"/>
|
|
<xs:element minOccurs="0" ref="mmi:statusInfo"/>
|
|
</xs:sequence>
|
|
<xs:attributeGroup ref="mmi:group.allResponseEvents.attrib"/>
|
|
</xs:complexType>
|
|
</xs:element>
|
|
</xs:schema>
|
|
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a name="d3e2097" id="d3e2097" />C.9 StartRequest.xsd</h3>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
|
<xs:schema xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" xmlns:xs="http://www.w3.org/2001/XMLSchema" attributeFormDefault="qualified" elementFormDefault="qualified" targetNamespace="http://www.w3.org/2008/04/mmi-arch">
|
|
<xs:annotation>
|
|
<xs:documentation xml:lang="en">
|
|
StartRequest schema for MMI Life cycle events version 1.0.
|
|
The Runtime Framework sends the event StartRequest to invoke a Modality Component
|
|
(to start loading a new GUI resource or to start the ASR or TTS). The Modality Component
|
|
must return a StartResponse event in response. If the Runtime Framework has sent a previous
|
|
PrepareRequest event, it may leave the contentURL and content fields empty, and the Modality
|
|
Component will use the values from the PrepareRequest event. If the Runtime Framework includes
|
|
new values for these fields, the values in the StartRequest event override those in the
|
|
PrepareRequest event.
|
|
</xs:documentation>
|
|
</xs:annotation>
|
|
<xs:include schemaLocation="mmi-datatypes.xsd"/>
|
|
<xs:include schemaLocation="mmi-attribs.xsd"/>
|
|
|
|
<xs:element name="StartRequest">
|
|
<xs:complexType>
|
|
<xs:choice>
|
|
<xs:sequence>
|
|
<xs:element name="ContentURL" type="mmi:contentURLType"/>
|
|
<xs:element minOccurs="0" name="data" type="mmi:anyComplexType"/>
|
|
</xs:sequence>
|
|
<xs:sequence>
|
|
<xs:element name="Content" type="mmi:anyComplexType"/>
|
|
<xs:element minOccurs="0" name="data" type="mmi:anyComplexType"/>
|
|
</xs:sequence>
|
|
</xs:choice>
|
|
<xs:attributeGroup ref="mmi:group.allEvents.attrib"/>
|
|
</xs:complexType>
|
|
</xs:element>
|
|
</xs:schema>
|
|
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a name="d3e2102" id="d3e2102" />C.10 StartResponse.xsd</h3>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|
<xs:schema xmlns:mmi="http://www.w3.org/2008/04/mmi-arch"
|
|
xmlns:xs="http://www.w3.org/2001/XMLSchema"
|
|
targetNamespace="http://www.w3.org/2008/04/mmi-arch"
|
|
attributeFormDefault="qualified"
|
|
elementFormDefault="qualified">
|
|
<xs:annotation>
|
|
<xs:documentation xml:lang="en">
|
|
StartResponse schema for MMI Life cycle events version 1.0
|
|
</xs:documentation>
|
|
</xs:annotation>
|
|
<xs:include schemaLocation="mmi-datatypes.xsd"/>
|
|
<xs:include schemaLocation="mmi-attribs.xsd"/>
|
|
<xs:include schemaLocation="mmi-elements.xsd"/>
|
|
|
|
<xs:element name="StartResponse">
|
|
<xs:complexType>
|
|
<xs:sequence>
|
|
<xs:element name="Data" minOccurs="0" type="mmi:anyComplexType"/>
|
|
<xs:element ref="mmi:StatusInfo" minOccurs="0"/>
|
|
</xs:sequence>
|
|
<xs:attributeGroup ref="mmi:group.allResponseEvents.attrib"/>
|
|
</xs:complexType>
|
|
</xs:element>
|
|
</xs:schema>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a name="d3e2107" id="d3e2107" />C.11 DoneNotification.xsd</h3>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
|
<xs:schema xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" xmlns:xs="http://www.w3.org/2001/XMLSchema" attributeFormDefault="qualified" elementFormDefault="qualified" targetNamespace="http://www.w3.org/2008/04/mmi-arch">
|
|
<xs:annotation>
|
|
<xs:documentation xml:lang="en">
|
|
DoneNotification schema for MMI Life cycle events version 1.0.
|
|
The DoneNotification event is intended to be used by the Modality Component to indicate that
|
|
it has reached the end of its processing. For the VUI-MC it can be used to return the ASR
|
|
recognition result (or the status info: noinput/nomatch) and TTS/Player done notification.
|
|
</xs:documentation>
|
|
</xs:annotation>
|
|
<xs:include schemaLocation="mmi-datatypes.xsd"/>
|
|
<xs:include schemaLocation="mmi-attribs.xsd"/>
|
|
<xs:include schemaLocation="mmi-elements.xsd"/>
|
|
|
|
<xs:element name="DoneNotification">
|
|
<xs:complexType>
|
|
<xs:sequence>
|
|
<xs:element minOccurs="0" name="data" type="mmi:anyComplexType"/>
|
|
<xs:element minOccurs="0" ref="mmi:statusInfo"/>
|
|
</xs:sequence>
|
|
<xs:attributeGroup ref="mmi:group.allResponseEvents.attrib"/>
|
|
</xs:complexType>
|
|
</xs:element>
|
|
</xs:schema>
|
|
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a name="d3e2112" id="d3e2112" />C.12 CancelRequest.xsd</h3>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
|
<xs:schema xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" xmlns:xs="http://www.w3.org/2001/XMLSchema" attributeFormDefault="qualified" elementFormDefault="qualified" targetNamespace="http://www.w3.org/2008/04/mmi-arch">
|
|
<xs:annotation>
|
|
<xs:documentation xml:lang="en">
|
|
CancelRequest schema for MMI Life cycle events version 1.0.
|
|
The CancelRequest event is sent by the Runtime Framework to stop processing in the Modality
|
|
Component (e.g. to cancel ASR or TTS/Playing). The Modality Component must return with a
|
|
CancelResponse message.
|
|
</xs:documentation>
|
|
</xs:annotation>
|
|
<xs:include schemaLocation="mmi-datatypes.xsd"/>
|
|
<xs:include schemaLocation="mmi-attribs.xsd"/>
|
|
|
|
<xs:element name="CancelRequest">
|
|
<xs:complexType>
|
|
<xs:attributeGroup ref="mmi:group.allEvents.attrib"/>
|
|
<!-- no elements -->
|
|
</xs:complexType>
|
|
</xs:element>
|
|
</xs:schema>
|
|
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a name="d3e2117" id="d3e2117" />C.13 CancelResponse.xsd</h3>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|
<xs:schema xmlns:mmi="http://www.w3.org/2008/04/mmi-arch"
|
|
xmlns:xs="http://www.w3.org/2001/XMLSchema"
|
|
targetNamespace="http://www.w3.org/2008/04/mmi-arch"
|
|
attributeFormDefault="qualified"
|
|
elementFormDefault="qualified">
|
|
<xs:annotation>
|
|
<xs:documentation xml:lang="en">
|
|
CancelResponse schema for MMI Life cycle events version 1.0.
|
|
The CancelRequest event is sent by the Runtime Framework to stop processing in the Modality
|
|
Component (e.g. to cancel ASR or TTS/Playing). The Modality Component must return with a
|
|
CancelResponse message.
|
|
</xs:documentation>
|
|
</xs:annotation>
|
|
<xs:include schemaLocation="mmi-datatypes.xsd"/>
|
|
<xs:include schemaLocation="mmi-attribs.xsd"/>
|
|
<xs:include schemaLocation="mmi-elements.xsd"/>
|
|
|
|
<xs:element name="CancelResponse">
|
|
<xs:complexType>
|
|
<xs:sequence>
|
|
<xs:element ref="mmi:StatusInfo" minOccurs="0"/>
|
|
</xs:sequence>
|
|
<xs:attributeGroup ref="mmi:group.allResponseEvents.attrib"/>
|
|
</xs:complexType>
|
|
</xs:element>
|
|
</xs:schema>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a name="d3e2122" id="d3e2122" />C.14 PauseRequest.xsd</h3>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|
<xs:schema xmlns:mmi="http://www.w3.org/2008/04/mmi-arch"
|
|
xmlns:xs="http://www.w3.org/2001/XMLSchema"
|
|
targetNamespace="http://www.w3.org/2008/04/mmi-arch"
|
|
attributeFormDefault="qualified"
|
|
elementFormDefault="qualified">
|
|
<xs:annotation>
|
|
<xs:documentation xml:lang="en">
|
|
PauseRequest schema for MMI Life cycle events version 1.0.
|
|
The PauseRequest event is sent by the Runtime Framework to pause processing of a Modality
|
|
Component (e.g. to cancel ASR or TTS/Playing). The Modality Component must return with a
|
|
PauseResponse message.
|
|
</xs:documentation>
|
|
</xs:annotation>
|
|
<xs:include schemaLocation="mmi-datatypes.xsd"/>
|
|
<xs:include schemaLocation="mmi-attribs.xsd"/>
|
|
|
|
<xs:element name="PauseRequest">
|
|
<xs:complexType>
|
|
<xs:attributeGroup ref="mmi:group.allEvents.attrib"/>
|
|
<!-- no elements -->
|
|
</xs:complexType>
|
|
</xs:element>
|
|
</xs:schema>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a name="d3e2127" id="d3e2127" />C.15 PauseResponse.xsd</h3>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|
<xs:schema xmlns:mmi="http://www.w3.org/2008/04/mmi-arch"
|
|
xmlns:xs="http://www.w3.org/2001/XMLSchema"
|
|
targetNamespace="http://www.w3.org/2008/04/mmi-arch"
|
|
attributeFormDefault="qualified"
|
|
elementFormDefault="qualified">
|
|
<xs:annotation>
|
|
<xs:documentation xml:lang="en">
|
|
PauseResponse schema for MMI Life cycle events version 1.0.
|
|
The PauseRequest event is sent by the Runtime Framework to pause the processing of
|
|
the Modality Component (e.g. to cancel ASR or TTS/Playing). The Modality Component
|
|
must return with a PauseResponse message.
|
|
</xs:documentation>
|
|
</xs:annotation>
|
|
<xs:include schemaLocation="mmi-datatypes.xsd"/>
|
|
<xs:include schemaLocation="mmi-attribs.xsd"/>
|
|
<xs:include schemaLocation="mmi-elements.xsd"/>
|
|
|
|
<xs:element name="PauseResponse">
|
|
<xs:complexType>
|
|
<xs:sequence>
|
|
<xs:element ref="mmi:StatusInfo" minOccurs="0"/>
|
|
</xs:sequence>
|
|
<xs:attributeGroup ref="mmi:group.allResponseEvents.attrib"/>
|
|
</xs:complexType>
|
|
</xs:element>
|
|
</xs:schema>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a name="d3e2132" id="d3e2132" />C.16 ResumeRequest.xsd</h3>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
|
<xs:schema xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" xmlns:xs="http://www.w3.org/2001/XMLSchema" attributeFormDefault="qualified" elementFormDefault="qualified" targetNamespace="http://www.w3.org/2008/04/mmi-arch">
|
|
<xs:annotation>
|
|
<xs:documentation xml:lang="en">
|
|
ResumeRequest schema for MMI Life cycle events version 1.0.
|
|
The ResumeRequest event is sent by the Runtime Framework to resume a previously suspended
|
|
processing task of a Modality Component. The Modality Component must return with a
|
|
ResumeResponse message.
|
|
</xs:documentation>
|
|
</xs:annotation>
|
|
<xs:include schemaLocation="mmi-datatypes.xsd"/>
|
|
<xs:include schemaLocation="mmi-attribs.xsd"/>
|
|
|
|
<xs:element name="ResumeRequest">
|
|
<xs:complexType>
|
|
<xs:attributeGroup ref="mmi:group.allEvents.attrib"/>
|
|
<!-- no elements -->
|
|
</xs:complexType>
|
|
</xs:element>
|
|
</xs:schema>
|
|
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a name="d3e2137" id="d3e2137" />C.17 ResumeResponse.xsd</h3>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|
<xs:schema xmlns:mmi="http://www.w3.org/2008/04/mmi-arch"
|
|
xmlns:xs="http://www.w3.org/2001/XMLSchema"
|
|
targetNamespace="http://www.w3.org/2008/04/mmi-arch"
|
|
attributeFormDefault="qualified"
|
|
elementFormDefault="qualified">
|
|
<xs:annotation>
|
|
<xs:documentation xml:lang="en">
|
|
ResumeRequest schema for MMI Life cycle events version 1.0.
|
|
The ResumeRequest event is sent by the Runtime Framework to resume a previously suspended
|
|
processing task of a Modality Component. The Modality Component must return with a
|
|
ResumeResponse message.
|
|
</xs:documentation>
|
|
</xs:annotation>
|
|
<xs:include schemaLocation="mmi-datatypes.xsd"/>
|
|
<xs:include schemaLocation="mmi-attribs.xsd"/>
|
|
<xs:include schemaLocation="mmi-elements.xsd"/>
|
|
|
|
<xs:element name="ResumeResponse">
|
|
<xs:complexType>
|
|
<xs:sequence>
|
|
<xs:element ref="mmi:StatusInfo" minOccurs="0"/>
|
|
</xs:sequence>
|
|
<xs:attributeGroup ref="mmi:group.allResponseEvents.attrib"/>
|
|
</xs:complexType>
|
|
</xs:element>
|
|
</xs:schema>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a name="d3e2142" id="d3e2142" />C.18
|
|
ExtensionNotification.xsd</h3>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
|
<xs:schema xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" xmlns:xs="http://www.w3.org/2001/XMLSchema" attributeFormDefault="qualified" elementFormDefault="qualified" targetNamespace="http://www.w3.org/2008/04/mmi-arch">
|
|
<xs:annotation>
|
|
<xs:documentation xml:lang="en">
|
|
ExtensionNotification schema for MMI Life cycle events version 1.0.
|
|
The extensionNotification event may be generated by either the Runtime Framework or the
|
|
Modality Component and is used to communicate (presumably changed) data values to the
|
|
other component. E.g. the VUI-MC has signaled a recognition result for any field displayed
|
|
on the GUI, the event will be used by the Runtime Framework to send a command to the
|
|
GUI-MC to update the GUI with the recognized value.
|
|
</xs:documentation>
|
|
</xs:annotation>
|
|
<xs:include schemaLocation="mmi-datatypes.xsd"/>
|
|
<xs:include schemaLocation="mmi-attribs.xsd"/>
|
|
|
|
<xs:element name="ExtensionNotification">
|
|
<xs:complexType>
|
|
<xs:sequence>
|
|
<xs:element minOccurs="0" name="data" type="mmi:anyComplexType"/>
|
|
</xs:sequence>
|
|
<xs:attributeGroup ref="mmi:group.allEvents.attrib"/>
|
|
<xs:attributeGroup ref="mmi:extension.name.attrib"/>
|
|
</xs:complexType>
|
|
</xs:element>
|
|
</xs:schema>
|
|
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a name="d3e2147" id="d3e2147" />C.19
|
|
ClearContextRequest.xsd</h3>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
|
<xs:schema xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" xmlns:xs="http://www.w3.org/2001/XMLSchema" attributeFormDefault="qualified" elementFormDefault="qualified" targetNamespace="http://www.w3.org/2008/04/mmi-arch">
|
|
<xs:annotation>
|
|
<xs:documentation xml:lang="en">
|
|
ClearContextRequest schema for MMI Life cycle events version 1.0
|
|
</xs:documentation>
|
|
</xs:annotation>
|
|
<xs:include schemaLocation="mmi-datatypes.xsd"/>
|
|
<xs:include schemaLocation="mmi-attribs.xsd"/>
|
|
<xs:include schemaLocation="mmi-elements.xsd"/>
|
|
|
|
<xs:element name="ClearContextRequest">
|
|
<xs:complexType>
|
|
<xs:attributeGroup ref="mmi:group.allEvents.attrib"/>
|
|
</xs:complexType>
|
|
</xs:element>
|
|
</xs:schema>
|
|
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a name="d3e2152" id="d3e2152" />C.20
|
|
ClearContextResponse.xsd</h3>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|
<xs:schema xmlns:mmi="http://www.w3.org/2008/04/mmi-arch"
|
|
xmlns:xs="http://www.w3.org/2001/XMLSchema"
|
|
targetNamespace="http://www.w3.org/2008/04/mmi-arch"
|
|
attributeFormDefault="qualified"
|
|
elementFormDefault="qualified">
|
|
<xs:annotation>
|
|
<xs:documentation xml:lang="en">
|
|
ClearContextResponse schema for MMI Life cycle events version 1.0
|
|
</xs:documentation>
|
|
</xs:annotation>
|
|
<xs:include schemaLocation="mmi-datatypes.xsd"/>
|
|
<xs:include schemaLocation="mmi-attribs.xsd"/>
|
|
<xs:include schemaLocation="mmi-elements.xsd"/>
|
|
|
|
<xs:element name="clearContextResponse">
|
|
<xs:complexType>
|
|
<xs:sequence>
|
|
<xs:element ref="mmi:statusInfo" minOccurs="0"/>
|
|
</xs:sequence>
|
|
<xs:attributeGroup ref="mmi:group.allResponseEvents.attrib"/>
|
|
</xs:complexType>
|
|
</xs:element>
|
|
</xs:schema>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a name="d3e2157" id="d3e2157" />C.21 StatusRequest.xsd</h3>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|
<xs:schema xmlns:mmi="http://www.w3.org/2008/04/mmi-arch"
|
|
xmlns:xs="http://www.w3.org/2001/XMLSchema"
|
|
targetNamespace="http://www.w3.org/2008/04/mmi-arch"
|
|
attributeFormDefault="qualified"
|
|
elementFormDefault="qualified">
|
|
<xs:annotation>
|
|
<xs:documentation xml:lang="en">
|
|
StatusRequest schema for MMI Life cycle events version 1.0.
|
|
The StatusRequest message and the corresponding StatusResponse are intended to provide keep-alive
|
|
functionality, informing the Runtime Framework about the presence of the various modality components.
|
|
Note that both messages are not tied to any context and may thus be sent independent of any user
|
|
interaction.
|
|
</xs:documentation>
|
|
</xs:annotation>
|
|
<xs:include schemaLocation="mmi-datatypes.xsd"/>
|
|
<xs:include schemaLocation="mmi-attribs.xsd"/>
|
|
|
|
<xs:element name="StatusRequest">
|
|
<xs:complexType>
|
|
<xs:attributeGroup ref="mmi:context.optional.attrib"/>
|
|
<xs:attributeGroup ref="mmi:source.attrib"/>
|
|
<xs:attributeGroup ref="mmi:target.attrib"/>
|
|
<xs:attributeGroup ref="mmi:requestID.attrib"/>
|
|
<xs:attributeGroup ref="mmi:requestAutomaticUpdate.attrib"/>
|
|
<!-- no elements -->
|
|
</xs:complexType>
|
|
</xs:element>
|
|
</xs:schema>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a name="d3e2162" id="d3e2162" />C.22 StatusResponse.xsd</h3>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|
<xs:schema xmlns:mmi="http://www.w3.org/2008/04/mmi-arch"
|
|
xmlns:xs="http://www.w3.org/2001/XMLSchema"
|
|
targetNamespace="http://www.w3.org/2008/04/mmi-arch"
|
|
attributeFormDefault="qualified"
|
|
elementFormDefault="qualified">
|
|
<xs:annotation>
|
|
<xs:documentation xml:lang="en">
|
|
StatusResponse schema for MMI Life cycle events version 1.0.
|
|
The StatusRequest message and the corresponding StatusResponse are intended to provide keep-alive
|
|
functionality, informing the Runtime Framework about the presence of the various modality components.
|
|
Note that both messages are not tied to any context and may thus be sent independent of any user
|
|
interaction.
|
|
</xs:documentation>
|
|
</xs:annotation>
|
|
<xs:include schemaLocation="mmi-datatypes.xsd"/>
|
|
<xs:include schemaLocation="mmi-attribs.xsd"/>
|
|
<xs:include schemaLocation="mmi-elements.xsd"/>
|
|
|
|
<xs:element name="StatusResponse">
|
|
<xs:complexType>
|
|
<xs:sequence>
|
|
<xs:element ref="mmi:StatusInfo" minOccurs="0"/>
|
|
</xs:sequence>
|
|
<xs:attributeGroup ref="mmi:context.optional.attrib"/>
|
|
<xs:attributeGroup ref="mmi:source.attrib"/>
|
|
<xs:attributeGroup ref="mmi:target.attrib"/>
|
|
<xs:attributeGroup ref="mmi:requestID.attrib"/>
|
|
<xs:attributeGroup ref="mmi:statusResponse.attrib"/>
|
|
<xs:attributeGroup ref="mmi:automaticUpdate.attrib"/>
|
|
</xs:complexType>
|
|
</xs:element>
|
|
</xs:schema>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div1">
|
|
<h2><a name="LadderDiagrams" id="LadderDiagrams" />D Ladder
|
|
Diagrams for the MMI Architecture with a Web Browser and VXML
|
|
Interpreter</h2>
|
|
|
|
[This section is informative]
|
|
|
|
<div class="div2">
|
|
<h3><a name="d3e2171" id="d3e2171" />D.1 Creating a Session</h3>
|
|
|
|
<p>The following ladder diagram shows a possible message sequence
|
|
upon a session creation. We assume that an Interaction Manager
|
|
session is already up and running. The user starts a multimodal
|
|
session for example by starting a web browser and fetching a given
|
|
URL.</p>
|
|
|
|
<p>The initial document contains scripts which providing the
|
|
modality component functionality (e.g. understanding XML formatted
|
|
life-cycle events) and message transport capabilities (e.g. AJAX,
|
|
but depends on the exact system implementation).</p>
|
|
|
|
<p>After loading the initial documents (and scripts) the modality
|
|
component implementation issues a mmi:NewContextRequest message to
|
|
the IM. The IM may load a corresponding markup document, if
|
|
necessary, and initializes and starts a new session.</p>
|
|
|
|
<p>In this scenario the Interaction Manager manager logic issues a
|
|
number of mmi:StartRequest messages to the various modality
|
|
components. One message is sent to the graphical modality component
|
|
(GUI) to instruct it to load a HTML document. Another message is
|
|
sent to a voice modality component (VUI) to play a welcome
|
|
message.</p>
|
|
|
|
<p>The voice modality component has (in this example) to create a
|
|
VoiceXML session. As VoiceXML 2.1 does not provide an external
|
|
event interface a CCXML session will be used for external
|
|
asynchronous communication. Therefore the voice modality component
|
|
uses the session creation interface of CCXML 1.0 to create a
|
|
session and start a corresponding script. This script will then
|
|
make a call to a phone at the user device (which could be a regular
|
|
phone or a SIP soft phone on the user's device). This scenario
|
|
illustrates the use of a SIP phone, which may reside on the users
|
|
mobile handset.</p>
|
|
|
|
<p>After successful setup of a CCXML session and the voice
|
|
connection the voice modality component instructs the CCXML browser
|
|
to start a VoiceXML dialog and passing it a corresponding VoiceXML
|
|
script. The VoiceXML interpreter will execute the script and play
|
|
out the welcome message. After the execution of the VoiceXML script
|
|
has finished, the voice modality component notifies the Interaction
|
|
Manager using the mmi:done event.</p>
|
|
|
|
<img class="center"
|
|
src="Images/MMI_SequenceDiagrams_1_create_session.png"
|
|
alt="session creation ladder" /></div>
|
|
|
|
<div class="div2">
|
|
<h3><a name="d3e2187" id="d3e2187" />D.2 Processing User Input</h3>
|
|
|
|
<p>The next diagram gives a example for the possible message flow
|
|
while processing of user input. In the given scenario the user
|
|
wants to enter information using the voice modality component. To
|
|
start the voice input the user has to use the "push-to-talk"
|
|
button. The "push-to-talk" button (which might be a hardware button
|
|
or a soft button on the screen) generates a corresponding event
|
|
when pushed. This event is issues as a mmi:Extension event towards
|
|
the Interaction Manager. The Interaction Manager logic sends a
|
|
mmi:StartRequest to the voice modality component. This
|
|
mmi:StartRequest message contains a URL which points to a
|
|
corresponding VoiceXML script. The voice modality component again
|
|
starts a VoiceXML interpreter using the given URL. The VoiceXML
|
|
interpreter loads the document and executes it. Now the system is
|
|
ready for the user input. To notify the user about the availability
|
|
of the voice input functionality the Interaction Manager might send
|
|
an event to the GUI upon receiving the mmi:StartResponse event
|
|
(which indicates that the voice modality component has started to
|
|
execute the document). But note that this is not shown in the
|
|
picture.</p>
|
|
|
|
<p>The VoiceXML interpreter captures the users voice input and uses
|
|
a speech recognition engine to recognize the utterance. The speech
|
|
recognition result will be represented as an EMMA document and sent
|
|
to the interaction manager using the mmi:done message. The
|
|
Interaction Manager logic sends a mmi:Extension message to the GUI
|
|
modality component to instruct it to display the recognition
|
|
result.</p>
|
|
|
|
<img class="center"
|
|
src="Images/MMI_SequenceDiagrams_2_processing_user_input.png"
|
|
alt="session creation ladder" /></div>
|
|
|
|
<div class="div2">
|
|
<h3><a name="d3e2195" id="d3e2195" />D.3 Ending a Session</h3>
|
|
|
|
<p>In the following scenario a modality component instance will be
|
|
destroyed as a reaction to a user input, e.g. because the user
|
|
selected to change to the GUI only mode. In this case a
|
|
mmi:ClearContextRequest will be issued to the voice modality
|
|
component. The voice modality component wrapper will then destroy
|
|
the CCXML (and VoiceXML) session.</p>
|
|
|
|
<p>The application logic (i.e. the IM) may also decide to indicate
|
|
the removed voice functionality and disable an icon on the screen
|
|
which indicates the availability of the voice modality.</p>
|
|
|
|
<img class="center"
|
|
src="Images/MMI_SequenceDiagrams_3_destroy_session.png"
|
|
alt="session creation ladder" /></div>
|
|
</div>
|
|
|
|
<div class="div1">
|
|
<h2><a name="LocalizationCustomization"
|
|
id="LocalizationCustomization" />E Localization and
|
|
Customization</h2>
|
|
|
|
[This section is informative]
|
|
|
|
<p>The MMI architecture specification describes a set of lifecycle
|
|
events which define the basic interface between the interaction
|
|
management and the modality components. The StartRequest lifecycle
|
|
event defines the "content" and "contentURL" elements which may
|
|
contain markup code (or references to markup code). The markup has
|
|
to be executed by the modality component. Using the "Content" or
|
|
"ContentURL" attributes introduces a dependency of the lifecycle
|
|
event to a specific modality component implementation. In other
|
|
words, the interaction manager has to issue different
|
|
StartRequests, depending on which markup a GUI modality component
|
|
may be able to process.</p>
|
|
|
|
<p>But multimodal applications may want to support different
|
|
modality component implementations, such as HTML or Flash, for the
|
|
same application. In this case the interaction manager should be
|
|
independent of the modality component implementation and hence not
|
|
generate a markup specific lifecycle event (e.g. containing a link
|
|
to HTML or even HTML content), but a further abstracted description
|
|
of the command.</p>
|
|
|
|
<p>Furthermore, localization needs to be taken into account. If the
|
|
interaction manager sends markup code to the modality component (or
|
|
references to it), this markup code should not contain any
|
|
dependencies to the user's language. Instead the interaction
|
|
manager needs to send the locale information to the modality
|
|
component and let it select the appropriate strings.</p>
|
|
|
|
<p>Here is an example to show, how these two issues could be
|
|
addressed within the lifecycle events. This example uses a generic
|
|
data structure to carry the locale information (within the xml:lang
|
|
attribute) and the data to be visualized at a GUI.</p>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0">
|
|
<mmi:startRequest mmi:requestID="123720476141" mmi:context="IM_dcc3c320-9e88-44fe-b91d-02bd02fba1e3" mmi:source="IM" mmi:target="GUI">
|
|
<mmi:contentURL mmi:href="login"/>
|
|
<mmi:data>
|
|
<gui resourceid="login" xml:lang="de-DE">
|
|
<data id="back" enabled="false"/>
|
|
<data id="next" enabled="false"/>
|
|
</gui>
|
|
</mmi:data>
|
|
</mmi:startRequest>
|
|
</mmi:mmi>
|
|
</pre>
|
|
</div>
|
|
|
|
<p>This StartRequest carries a generic <gui> structure as its
|
|
payload which contains a "resourceid" and the xml:lang information.
|
|
The "resourceid" has to be interpreted by the modality component
|
|
(either to load an HTML document or a corresponding dialog, e.g. if
|
|
it is a flash app), whereas "xml:lang" is used by the modality
|
|
component to select the appropriate string tables.</p>
|
|
|
|
<p>The content of the <gui> structure is an application
|
|
specific (but generic) description of data to be used by the
|
|
modality component. This could contain a description of the status
|
|
of GUI elements (such as "enabled" or "disabled") or a list of
|
|
items to be displayed. The following example shows a StartRequest
|
|
to display a list of music songs. The list of songs will be loaded
|
|
from a backend system and are dynamic. The representation of the
|
|
song list is agnostic to the modality component implementation. It
|
|
is the responsibility of the modality component to interpret the
|
|
structure and to display its content appropriately.</p>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0">
|
|
<mmi:startRequest mmi:requestID="123720967758" mmi:context="IM_dcc3c320-9e88-44fe-b91d-02bd02fba1e3" mmi:source="IM" mmi:target="GUI">
|
|
<mmi:contentURL mmi:href="songSelection"/>
|
|
<mmi:data>
|
|
<gui resourceid="songSelection" xml:lang="de-DE">
|
|
<data id="back" enabled="true"/>
|
|
<data id="next" enabled="false"/>
|
|
<data id="titleList" selected="" enabled="true">
|
|
<items>
|
|
<item id="10">
|
|
<arg name="artist"><![CDATA[One artist]]>
|
|
</arg>
|
|
<arg name="title"><![CDATA[This is the title]]>
|
|
</arg>
|
|
<arg name="displayName"><![CDATA[Title]]>
|
|
</arg>
|
|
<arg name="price"><![CDATA[0.90]]>
|
|
</arg>
|
|
</item>
|
|
<item id="11">
|
|
<arg name="artist"><![CDATA[Another artist]]>
|
|
</arg>
|
|
<arg name="title"><![CDATA[Yet another title]]>
|
|
</arg>
|
|
<arg name="displayName"><![CDATA[2nd title]]>
|
|
</arg>
|
|
<arg name="price"><![CDATA[0.90]]>
|
|
</arg>
|
|
</item>
|
|
</items>
|
|
</data>
|
|
</gui>
|
|
</mmi:data>
|
|
</mmi:startRequest>
|
|
</mmi:mmi>
|
|
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div1">
|
|
<h2><a name="HTTPTransport" id="HTTPTransport" />F HTTP transport
|
|
of MMI lifecycle events</h2>
|
|
|
|
[This section is informative]
|
|
|
|
<p>The "Multimodal Architecture and Interfaces" specification
|
|
supports deployments in a variety of topologies, either distributed
|
|
or co-located. In case of a distributed deployment, a protocol for
|
|
the lifecycle event transport needs to be defined. HTTP is the
|
|
major protocol of the web. HTTP is widely adopted, it is supported
|
|
by many programming languages and especially used by web browsers.
|
|
Technologies like AJAX provide asynchronous transmission of
|
|
messages for web browsers and allow to build modality components on
|
|
top of it in distributed environments. This section describes how
|
|
the HTTP protocol should be used for MMI lifecycle event transport
|
|
in distributed deployments. Modality components and the Interaction
|
|
Manager need an HTTP processor to send and receive MMI lifecycle
|
|
events. The following picture illustrates a possible modularization
|
|
of the Runtime Framework, the Interaction Manager and the Modality
|
|
Components. It shows internal lifecycle event interfaces (which
|
|
abstract from the transport layer) and the HTTP processors. The
|
|
HTTP processors are responsible for assembling and disassembling of
|
|
HTTP requests, which carry MMI lifecycle event representations as
|
|
payloads.</p>
|
|
|
|
<img class="center" src="Images/HTTP_lifecycle_transport_1.png"
|
|
alt="" />
|
|
<p>The following sections describe, how the HTTP protocol should be
|
|
used to transport MMI lifecycle events.</p>
|
|
|
|
<p>HTTP defines the concept of client and server <a
|
|
href="#RFC2616">[RFC2616]</a>. One possible deployment of the
|
|
multimodal architecture is shown in following figure:</p>
|
|
|
|
<img class="center" src="Images/HTTP_lifecycle_transport_2.png"
|
|
alt="" />
|
|
<p>In this deployment scenario the Interaction Manager acts as an
|
|
HTTP server, whereas modality components are HTTP clients, sending
|
|
HTTP requests to the Interaction Manager. But other configurations
|
|
are possible.</p>
|
|
|
|
<div class="div2">
|
|
<h3><a name="d3e2240" id="d3e2240" />F.1 Lifecycle event transport
|
|
from modality components to Interaction Manager</h3>
|
|
|
|
<p>The multimodal architecture specification requires an
|
|
asynchronous bi-directional event transmission. To achieve this (in
|
|
the given scenario, where modality components are HTTP clients and
|
|
the Interaction Manager acts as an HTTP server) separate (parallel)
|
|
HTTP requests (referred to as send and receive channels in the
|
|
picture) are used to send and receive lifecycle events.</p>
|
|
|
|
<img class="center" src="Images/HTTP_lifecycle_transport_3.png"
|
|
alt="" />
|
|
<p>Modality components use HTTP/POST requests to send MMI lifecycle
|
|
events to the IM. The request contains the following URL request
|
|
parameters:</p>
|
|
|
|
<ul>
|
|
<li><code>Context</code> (or <code>token</code>)</li>
|
|
|
|
<li><code>Source</code></li>
|
|
</ul>
|
|
|
|
<p>The lifecycle event itself is contained in the body of the
|
|
HTTP/POST request. The <code>Content-Type</code> header field of
|
|
the HTTP/POST request has to be set according to the lifecycle
|
|
event format, e.g. “text/xml”.</p>
|
|
|
|
<p>The URL request parameters <code>Context</code> and
|
|
<code>Source</code> are equivalent to the respective MMI lifecycle
|
|
event attributes. The <code>Context</code> must be used whenever
|
|
available. The <code>Context</code> is only unknown to the modality
|
|
component during startup of a multimodal session, as the
|
|
<code>Context</code> will be returned from the Interaction Manager
|
|
to the Modality component with the <code>NewContextResponse</code>
|
|
lifecycle event. Hence, when sending a
|
|
<code>NewContextRequest</code>, the context is unknown. Therefore a
|
|
<code>token</code> is used to associate the
|
|
<code>NewContextRequest</code> and <code>NewContextResponse</code>
|
|
messages.</p>
|
|
|
|
<p>The <code>token</code> is a unique id (preexisting knowledge,
|
|
e.g. generated by the modality component during registration) to
|
|
identify the channel between a modality component and the
|
|
Interaction Manager.</p>
|
|
|
|
<p>Once the <code>Context</code> is exchanged, the
|
|
<code>Context</code> must be used with subsequent requests and the
|
|
<code>token</code> must not be used anymore.</p>
|
|
|
|
<p>The response (to a HTTP/POST request, which carries a lifecycle
|
|
event from a Modality Component to to the Interaction Manager) must
|
|
not contain any content and the HTTP response code must be “204 No
|
|
Content”.</p>
|
|
|
|
<p>The HTTP processor of the Interaction Manager is expected to
|
|
handle POST requests (which contain lifecycle events sent from the
|
|
modality component to the Interaction Manager) as following:</p>
|
|
|
|
<ul>
|
|
<li>use the <code>context</code> (or <code>token</code>) parameter
|
|
to identify the corresponding interaction manager session</li>
|
|
|
|
<li>read lifecycle event from request body</li>
|
|
|
|
<li>forward MMI event to corresponding Interaction Manager
|
|
session</li>
|
|
|
|
<li>return "204 No Content" HTTP status code in case of success or
|
|
4XX/5XX codes in case of failure (see error handling section
|
|
below)</li>
|
|
</ul>
|
|
|
|
<br />
|
|
<br />
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a name="d3e2332" id="d3e2332" />F.2 Lifecycle event transport
|
|
from IM to modality components (HTTP clients only)</h3>
|
|
|
|
Modality components, which are not HTTP servers (such as modality
|
|
components build on top of web browsers) are not able to receive
|
|
HTTP requests. Thus, to receive MMI events from the Interaction
|
|
Manager, such modality components need to poll for events. The
|
|
modality component has to send an HTTP/GET request to the
|
|
Interaction Manager to request for the next MMI event. For network
|
|
performance optimization the HTTP processor of the Interaction
|
|
Manager may block the HTTP request for a certain time to avoid
|
|
delay and network traffic (long living HTTP request). The modality
|
|
component may control the maximum delay using the optional
|
|
parameter <code>timeout</code> (in milliseconds). The request
|
|
contains the following URL request parameters:
|
|
|
|
<ul>
|
|
<li><code>Context</code> (or <code>token</code>)</li>
|
|
|
|
<li><code>Source</code></li>
|
|
|
|
<li><code>timeout</code> (optional)</li>
|
|
</ul>
|
|
|
|
<p>See discussion of the parameter <code>Context</code> in the
|
|
previous section. The parameter <code>Source</code> describes the
|
|
source of the request, i.e. the modality components id. The
|
|
parameter <code>timeout</code> is optional and describes the
|
|
maximum delay in milliseconds. Only positive integer values are
|
|
allowed for the parameter <code>timeout</code>. The request with
|
|
<code>timeout</code> set to “0” returns immediately. The
|
|
Interaction Manager may limit the timeout to a (platform specific)
|
|
maximum value. In case of absence of the parameter
|
|
<code>timeout</code> the Interaction Manager uses a platform
|
|
specific default.</p>
|
|
|
|
<p>The HTTP response body contains the lifecycle event as a string.
|
|
The HTTP response header must contain the <code>Content-Type</code>
|
|
header field, which describes the format of the lifecycle event
|
|
string (e.g. “text/xml”).</p>
|
|
|
|
<p>The HTTP processor of the Interaction Manager is expected to
|
|
handle HTTP/GET requests (which are used by the Modality Component
|
|
to receive lifecycle events) as following:</p>
|
|
|
|
<ul>
|
|
<li>use <code>Context</code> (or <code>token</code>) parameter to
|
|
identify the corresponding Interaction Manager session</li>
|
|
|
|
<li>use <code>Source</code> parameter to identify modality
|
|
component id</li>
|
|
|
|
<li>check for corresponding events (i.e. are there events to send
|
|
from Interaction Manager to this particular Modality Component).
|
|
This step might be blocking for a certain time (according to
|
|
timeout parameter) to optimize network performance.</li>
|
|
|
|
<li>generate HTTP response containing lifecycle event string (and
|
|
set <code>Content-Type</code> header field appropriately). Use "200
|
|
OK" HTTP status code in case an event is contained in the response,
|
|
“204 No Content” in case of timeout or 4XX/5XX codes in case of
|
|
failure (see error handling section below)</li>
|
|
</ul>
|
|
|
|
<br />
|
|
<br />
|
|
<p>The following figure shows a sequence of HTTP requests: <img
|
|
class="center" src="Images/HTTP_lifecycle_transport_4.png"
|
|
alt="" /> <img class="center"
|
|
src="Images/HTTP_lifecycle_transport_5.png" alt="" /></p>
|
|
|
|
<p>If the IM receives a HTTP/GET request containing an invalid
|
|
<code>token</code> or <code>context</code>, it must return a 409
|
|
(Conflict) response code.</p>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a name="d3e2419" id="d3e2419" />F.3 Lifecycle event transport
|
|
from Interaction Manager to modality components (HTTP servers)</h3>
|
|
|
|
<p>For modality components, which are HTTP servers themselves, the
|
|
Interaction Manager needs to send a lifecycle event through an
|
|
HTTP/POST request. The request contains the following
|
|
parameters:</p>
|
|
|
|
<ul>
|
|
<li><code>Context</code></li>
|
|
|
|
<li><code>Target</code></li>
|
|
</ul>
|
|
|
|
See discussion of parameters in previous sections. Again, the
|
|
parameter <code>Target</code> is equivalent to the corresponding
|
|
MMI lifecycle event attribute and describes the receiver of the
|
|
event. Hence, the receiver of the HTTP request uses this parameter
|
|
to identify the corresponding modality component. <br />
|
|
<br />
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a name="d3e2435" id="d3e2435" />F.4 Error handling</h3>
|
|
|
|
<p>Various MMI lifecycle events (especially response events)
|
|
contain <em>Status</em> and <em>StatusInfo</em> fields. These
|
|
fields should be used for error indication whenever possible.
|
|
However, a failure during delivery of a lifecycle event needs to be
|
|
indicated using HTTP response codes.</p>
|
|
|
|
<p>The HTTP processor of the Interaction Manager has to use HTTP
|
|
response codes to indicate success or errors during request
|
|
handling. In case of a successful processing of a request
|
|
(successful in terms of transport, i.e. an event has been
|
|
successfully delivered) a 2XX status code (e.g. "204 No Content")
|
|
has to be returned. Transport related errors, which lead to failure
|
|
in delivery of a lifecycle event, are indicated using 4XX or 5XX
|
|
response codes. 4XX error codes referring to "client errors" (wrong
|
|
parameters etc.) whereas 5XX error codes indicating server errors
|
|
(see also HTTP response codes in <a
|
|
href="#RFC2616">[RFC2616]</a>).</p>
|
|
|
|
<p>The treatment of transport errors is up to the implementation,
|
|
but the implementation should make errors visible to author code
|
|
(e.g. raise event within Interaction Manager when a lifecycle event
|
|
has not been successfully delivered to a Modality Component).</p>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div1">
|
|
<h2><a name="glossary" id="glossary" />G Glossary</h2>
|
|
|
|
[This section is informative]
|
|
|
|
<ul>
|
|
<li>CCXML: <a href="#CCXML">[CCXML]</a> is designed to provide
|
|
telephony call control support for dialog systems, such as
|
|
VoiceXML.</li>
|
|
|
|
<li>Controller Document: A document that contains markup defining
|
|
the interaction between the other documents. Such markup is called
|
|
Interaction Manager markup.</li>
|
|
|
|
<li>Data Component: The Data Component is a sub-component of the
|
|
Runtime Framework which is responsible for storing
|
|
application-level data.</li>
|
|
|
|
<li>Interaction Manager: The Interaction Manager (IM) is the
|
|
component that is responsible for handling all life-cycle events
|
|
that the other Components generate. It is responsible for
|
|
synchronization of data and focus, etc., across different Modality
|
|
Components as well as the higher-level application flow that is
|
|
independent of Modality Components.</li>
|
|
|
|
<li>Life cycle events: The Multimodal Architecture defines basic
|
|
life-cycle events which must be supported by all modality
|
|
components. These events allow the Runtime Framework to invoke
|
|
modality components and receive results from them. They form the
|
|
basic interface between the Runtime Framework and the Modality
|
|
components.</li>
|
|
|
|
<li>Modality Component: Modality Components are responsible for
|
|
controlling the various input and output modalities on the device.
|
|
Modality components may also be used to perform general processing
|
|
functions not directly associated with any specific interface
|
|
modality, for example, dialog flow control or natural language
|
|
processing</li>
|
|
|
|
<li>Nested components: An Interaction Manager and a set of
|
|
Components can present themselves as a Component to a higher-level
|
|
Framework. All that is required is that the IM implement the
|
|
Component API. The result is a "Russian Doll" model in which
|
|
Components may be nested inside other Components to an arbitrary
|
|
depth.</li>
|
|
|
|
<li>Runtime Framework: The Runtime Framework is responsible for
|
|
starting the application and interpreting the Controller Document.
|
|
It provides the basic infrastructure into which the IM and the
|
|
various Modality Components plug into and controls the
|
|
communication among the other Constituents.</li>
|
|
|
|
<li>SCXML: "State Chart extensible Markup Language". <a
|
|
href="#SCXML">[SCXML]</a> provides a generic state-machine based
|
|
execution environment based on CCXML and Harel State Tables.</li>
|
|
|
|
<li>Software Constituent: An architecturally significant entity in
|
|
the architecture. Because we are using the term 'Component' to
|
|
refer to a specific set of entities in our architecture, we will
|
|
use the term 'Constituent' as a cover term for all the elements in
|
|
our architecture which might normally be called 'software
|
|
components'.</li>
|
|
|
|
<li>VoiceXML: <a href="#VoiceXML">[VoiceXML]</a> is designed for
|
|
creating audio dialogs that feature synthesized speech, digitized
|
|
audio, recognition of spoken and DTMF key input, recording of
|
|
spoken input, telephony, and mixed initiative conversations.</li>
|
|
</ul>
|
|
</div>
|
|
|
|
<div class="div1">
|
|
<h2><a name="creating_MC" id="creating_MC" />H Types of Modality
|
|
Components</h2>
|
|
|
|
[This section is informative]
|
|
|
|
<div class="div2">
|
|
<h3><a name="Simple_modality_components"
|
|
id="Simple_modality_components" />H.1 Simple modality
|
|
components</h3>
|
|
|
|
<p>Modality components can be classified into either of three
|
|
categories: simple, complex or nested.</p>
|
|
|
|
<p>A simple modality component presents information to a user or
|
|
captures information from a user as directed by an interaction
|
|
manager. A simple modality component is atomic in that it can not
|
|
be portioned into two or ore simple modality components that send
|
|
events among themselves. A simple modality component is like a
|
|
black box in that the interaction manager can not directly access
|
|
any function inside of the black box other than by using life-cycle
|
|
events.</p>
|
|
|
|
<p>A simple modality component might contain functionality to
|
|
present one of the following types of information to the user or
|
|
user agent. For example:</p>
|
|
|
|
<ul>
|
|
<li>TTS—generates synthetic speech from a text string</li>
|
|
|
|
<li>Audio replay—replays an audio file to a user</li>
|
|
|
|
<li>GUI presentation—presents HTML on a display device.</li>
|
|
|
|
<li>Ink replay—replays one or more ink strokes</li>
|
|
|
|
<li>Video replay—replays one or more video clips</li>
|
|
</ul>
|
|
|
|
<p>A simple modality component might contain functionality to
|
|
capture one of the following types of information from the user or
|
|
user agent as directed by a complex modality or interaction
|
|
manager:</p>
|
|
|
|
<ul>
|
|
<li>Audio capture—records user utterances</li>
|
|
|
|
<li>ASR—captures text from the user by using a grammar to convert
|
|
spoken voice into text</li>
|
|
|
|
<li>DTMF—captures integers from a user by using a grammar a user
|
|
capture digits represented by the sounds created by touch tone
|
|
keypad on a phone</li>
|
|
|
|
<li>Ink capture—capture one or more ink strokes</li>
|
|
|
|
<li>Ink recognition—captures one or more ink strokes and interprets
|
|
them as text by using a grammar.</li>
|
|
|
|
<li>Speaker verification—determines if a user is who the user
|
|
claims to be by comparing spoken voice characteristics with the
|
|
voice characteristics known to be associated with the user</li>
|
|
|
|
<li>Speaker identification—determines who a speak is by comparing
|
|
spoken voice characteristics with a set of preexisting voice
|
|
characteristics of several individuals.</li>
|
|
|
|
<li>Face verification—determines if a user is who the user claims
|
|
to be by comparing face patterns with the face patterns known to be
|
|
associated with the user</li>
|
|
|
|
<li>Face identification—determines who a speak is by comparing face
|
|
pattern characteristics with a set of preexisting face patterns of
|
|
several individuals</li>
|
|
|
|
<li>GPS—captures the current GPS location of a device.</li>
|
|
|
|
<li>Keyboard or mouse—captures information entered by the user
|
|
using a keyboard or mouse.</li>
|
|
</ul>
|
|
|
|
<img class="center" src="Images/figure1.png"
|
|
alt="Two simple modality components" />
|
|
<p class="caption">Figure 1: Two simple modality components</p>
|
|
|
|
<p>Figure 1 illustrates two simple modality components—ASR modality
|
|
for capturing input from the user and TTS for presenting output to
|
|
the user. Note that all information exchanged between the two
|
|
modality components must be sent as life-cycle events to the
|
|
interaction manager which forwards them to the other modality
|
|
component.</p>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a name="Complex_modality_components"
|
|
id="Complex_modality_components" />H.2 Complex modality
|
|
components</h3>
|
|
|
|
<p>A complex modality component may contain functionality of two or
|
|
more simple modality components, for example:</p>
|
|
|
|
<ul>
|
|
<li>GUI—presents information to the user, and captures keystrokes
|
|
and mouse movements</li>
|
|
|
|
<li>VXML—presents a VoiceXML dialog to the user that both present
|
|
speech to the user and captures the user's speech</li>
|
|
|
|
<li>GUI/VUI—enables user to both speak and listen, and read and
|
|
type.</li>
|
|
</ul>
|
|
|
|
<img class="center" src="Images/figure2.png"
|
|
alt="A basic modality component with two functions" />
|
|
<p class="caption">Figure 2: A basic modality component with two
|
|
functions</p>
|
|
|
|
<p>Figure 2 illustrates a complex modality component containing two
|
|
functions, ASR and TTS. The ASR and TTS functions within the
|
|
complex modality component may communicate directly with each
|
|
other, in addition to sending and receiving life-cycle events with
|
|
the interaction manager</p>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a name="Nested_modality_components"
|
|
id="Nested_modality_components" />H.3 Nested modality
|
|
components</h3>
|
|
|
|
<p>A nested modality component is a set of modality components and
|
|
a script (possibly written in SCXML) that manages them. The script
|
|
communicates with the child modality components using life cycle
|
|
events. The script communicates with the interaction manager using
|
|
only life-cycle events. The child modality components may not
|
|
communicate directly with each other.</p>
|
|
|
|
<img class="center" src="Images/figure3.png"
|
|
alt="A nested modality component with two child modality components, ASR and TTS" />
|
|
<p class="caption">Figure 3: A nested modality component with two
|
|
child modality components, ASR and TTS.</p>
|
|
|
|
<p>Figure 3 illustrates a nested modality component with two child
|
|
modality components, ASR and TTS.</p>
|
|
|
|
<p>In effect, the script within a nested modality component can be
|
|
thought of as an interaction manager that manages the child
|
|
modality components. In effect, a nested modality component is a
|
|
nested interaction manager. This is the so-called "Russian Doll"
|
|
model of nested interaction managers.</p>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div1">
|
|
<h2><a name="references" id="references" />I Normative
|
|
References</h2>
|
|
|
|
<dl>
|
|
<dt class="label"><a name="RFC2119" id="RFC2119" />IETF RFC
|
|
2119</dt>
|
|
|
|
<dd><a href="http://www.ietf.org/rfc/rfc2119.txt"><cite>RFC 2119:
|
|
Key words for use in RFCs to Indicate Requirement
|
|
Levels</cite></a>. Internet Engineering Task Force, 1997. (See
|
|
http://www.ietf.org/rfc/rfc2119.txt.)</dd>
|
|
|
|
<dt class="label"><a name="RFC2396" id="RFC2396" />IETF RFC
|
|
2396</dt>
|
|
|
|
<dd><a href="http://www.ietf.org/rfc/rfc2396.txt"><cite>RFC 2396:
|
|
Uniform Resource Identifiers</cite></a>. Internet Engineering Task
|
|
Force, 1995. (See http://www.ietf.org/rfc/rfc2396.txt.)</dd>
|
|
|
|
<dt class="label"><a name="RFC2616" id="RFC2616" />RFC2616</dt>
|
|
|
|
<dd><a href="http://www.ietf.org/rfc/rfc2616.txt"><cite>"Hypertext
|
|
Transfer Protocol -- HTTP/1.1"</cite></a> , R. Fielding et al.
|
|
editors. IETF, 1999.</dd>
|
|
</dl>
|
|
</div>
|
|
|
|
<div class="div1">
|
|
<h2><a name="d3e2590" id="d3e2590" />J Informative References</h2>
|
|
|
|
<dl>
|
|
<dt class="label"><a name="CCXML" id="CCXML" />CCXML</dt>
|
|
|
|
<dd><a href="http://www.w3.org/TR/ccxml/"><cite>"Voice Browser Call
|
|
Control: CCXML Version 1.0"</cite></a> , R.J. Auburn, editor, World
|
|
Wide Web Consortium, 2005.</dd>
|
|
|
|
<dt class="label"><a name="EMMA" id="EMMA" />EMMA</dt>
|
|
|
|
<dd><a href="http://www.w3.org/TR/emma/"><cite>"Extensible
|
|
multimodal Annotation markup language (EMMA)"</cite></a>, Michael
|
|
Johnson et al. editors. EMMA is an XML format for annotating
|
|
application specific interpretations of user input with information
|
|
such as confidence scores, time stamps, input modality and
|
|
alternative recognition hypotheses, World Wide Web Consortium,
|
|
2005.</dd>
|
|
|
|
<dt class="label"><a name="Communicator"
|
|
id="Communicator" />Galaxy</dt>
|
|
|
|
<dd><a href="http://communicator.sourceforge.net/"><cite>"Galaxy
|
|
Communicator"</cite></a> Galaxy Communicator is an open source hub
|
|
and spoke architecture for constructing dialogue systems that was
|
|
developed with funding from Defense Advanced Research Projects
|
|
Agency (DARPA) of the United States Government.</dd>
|
|
|
|
<dt class="label"><a name="MMIF" id="MMIF" />MMIF</dt>
|
|
|
|
<dd><a href="http://www.w3.org/TR/mmi-framework/"><cite>"W3C
|
|
Multimodal Interaction Framework"</cite></a> , James A. Larson,
|
|
T.V. Raman and Dave Raggett, editors, World Wide Web Consortium,
|
|
2003.</dd>
|
|
|
|
<dt class="label"><a name="MMIUse" id="MMIUse" />MMIUse</dt>
|
|
|
|
<dd><a
|
|
href="http://www.w3.org/TR/mmi-use-cases/#driving-dir"><cite>"W3C
|
|
Multimodal Interaction Use Cases"</cite></a>, Emily Candell and
|
|
Dave Raggett, editors, World Wide Web Consortium, 2002.</dd>
|
|
|
|
<dt class="label"><a name="SCXML" id="SCXML" />SCXML</dt>
|
|
|
|
<dd><a
|
|
href="http://www.w3.org/TR/2006/WD-scxml-20060124/"><cite>"State
|
|
Chart XML (SCXML): State Machine Notation for Control
|
|
Abstraction"</cite></a> , Jim Barnett et al. editors. World Wide
|
|
Web Consortium, 2006.</dd>
|
|
|
|
<dt class="label"><a name="SMIL" id="SMIL" />SMIL</dt>
|
|
|
|
<dd><a
|
|
href="http://www.w3.org/TR/2005/REC-SMIL2-20051213/"><cite>"Synchronized
|
|
Multimedia Integration Language (SMIL 2.1)"</cite></a> , Dick
|
|
Bulterman et al. editors. World Wide Web Consortium, 2005.</dd>
|
|
|
|
<dt class="label"><a name="SVG" id="SVG" />SVG</dt>
|
|
|
|
<dd><a href="http://www.w3.org/TR/SVG11/"><cite>"Scalable Vector
|
|
Graphics (SVG) 1.1 Specification"</cite></a> , Jon Ferraiolo et al.
|
|
editors. World Wide Web Consortium, 2003.</dd>
|
|
|
|
<dt class="label"><a name="VoiceXML" id="VoiceXML" />VoiceXML</dt>
|
|
|
|
<dd><a href="http://www.w3.org/TR/voicexml20/"><cite>"Voice
|
|
Extensible Markup Language (VoiceXML) Version 2.0"</cite></a> ,
|
|
Scott McGlashan et al. editors. World Wide Web Consortium,
|
|
2004.</dd>
|
|
|
|
<dt class="label"><a name="HTML" id="HTML" />HTML</dt>
|
|
|
|
<dd><a
|
|
href="http://www.w3.org/TR/1999/REC-html401-19991224/"><cite>"HTML
|
|
4.01 Specification"</cite></a> , Raggett et al. editors. World Wide
|
|
Web Consortium, 1999.</dd>
|
|
|
|
<dt class="label"><a name="XMLSig" id="XMLSig" />XMLSig</dt>
|
|
|
|
<dd><a
|
|
href="http://www.w3.org/TR/2001/PR-xmldsig-core-20010820/"><cite>"XML-Signature
|
|
Syntax and Processing"</cite></a> Eastlake et al., editors. World
|
|
Wide Web Consortium, 2001.</dd>
|
|
</dl>
|
|
</div>
|
|
</div>
|
|
</body>
|
|
</html>
|
|
|