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.
1503 lines
42 KiB
1503 lines
42 KiB
<!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">
|
|
<head>
|
|
<meta name="generator" content="HTML Tidy, see www.w3.org" />
|
|
<meta http-equiv="Content-Type"
|
|
content="text/html; charset=iso-8859-1" />
|
|
<link rel="stylesheet" type="text/css"
|
|
href="http://www.w3.org/StyleSheets/TR/W3C-WD.css" /><?xml-stylesheet
|
|
type="text/css"
|
|
href="http://www.w3.org/StyleSheets/TR/W3C-WD.css"?>
|
|
<style type="text/css">
|
|
body {
|
|
margin: 2em 1em 2em 70px;
|
|
font-family: sans-serif;
|
|
color: black;
|
|
background-color: white;
|
|
background-attachment: fixed;
|
|
background-image: url(http://www.w3.org/StyleSheets/TR/WD.gif);
|
|
background-position: top left;
|
|
background-repeat: no-repeat;
|
|
}
|
|
h1,h2,h3,h4,h5,h6,ul,p,dl,dd,dt {font-family: sans-serif}
|
|
h1,h2 { color: rgb(0, 92, 160) }
|
|
h3 { font-size: 120%; font-weight: bold }
|
|
h4 { font-size: 100% }
|
|
.notoc { font-weight: normal }
|
|
:link { color: rgb(0, 0, 153) }
|
|
:visited { color: rgb(153, 0, 153) }
|
|
:active { color: rgb(255, 0, 102) }
|
|
a :hover { color: rgb(0, 0, 255) }
|
|
.comment { font-style: italic; color: teal;}
|
|
.tocline { list-style: none; marker-offset: 1em; }
|
|
.note {
|
|
background-color: rgb(230,230,255);
|
|
padding: 0.5em;
|
|
border: none;
|
|
margin-right: 0%;
|
|
font-style: italic;
|
|
}
|
|
</style>
|
|
|
|
<title>Reusable dialog requirements</title>
|
|
</head>
|
|
<body>
|
|
<div class="head"><a href="http://www.w3.org/"><img
|
|
src="http://www.w3.org/Icons/w3c_home" alt="W3C"
|
|
border="0" /></a>
|
|
|
|
<h1 class="notoc">Reusable Dialog Requirements<br />
|
|
for Voice Markup Language</h1>
|
|
|
|
<h2 class="notoc">W3C Working Draft 26 April 2000</h2>
|
|
|
|
<dl>
|
|
<dt>This Version:</dt>
|
|
|
|
<dd><a class="publoc"
|
|
href="http://www.w3.org/TR/2000/WD-reusable-dialog-reqs-20000426">
|
|
http://www.w3.org/TR/2000/WD-reusable-dialog-reqs-20000426</a></dd>
|
|
|
|
<dt>Latest Version:</dt>
|
|
|
|
<dd><a class="publoc"
|
|
href="http://www.w3.org/TR/reusable-dialog-reqs">
|
|
http://www.w3.org/TR/reusable-dialog-reqs</a></dd>
|
|
|
|
<dt> </dt>
|
|
|
|
<dt>Editor:</dt>
|
|
|
|
<dd>Daniel C. Burnett <<a
|
|
href="mailto:burnett@nuance.com">burnett@nuance.com</a>></dd>
|
|
</dl>
|
|
|
|
<p class="copyright"><a
|
|
href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">
|
|
Copyright</a>© 2000 <a href="http://www.w3.org/"><abbr
|
|
title="World Wide Web Consortium">W3C</abbr></a><sup>®</sup>
|
|
(<a href="http://www.lcs.mit.edu/"><abbr
|
|
title="Massachusetts Institute of Technology">MIT</abbr></a>, <a
|
|
href="http://www.inria.fr/"><abbr lang="fr"
|
|
title="Institut National de Recherche en Informatique et Automatique">
|
|
INRIA</abbr></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>, <a
|
|
href="http://www.w3.org/Consortium/Legal/copyright-documents-19990405">
|
|
document use</a> and <a
|
|
href="http://www.w3.org/Consortium/Legal/copyright-software-19980720">
|
|
software licensing</a> rules apply.</p>
|
|
</div>
|
|
|
|
<hr title="Separator for header" />
|
|
<h2><a id="abstract" name="abstract"></a>Abstract</h2>
|
|
|
|
<p>The W3C Voice Browser working group aims to develop
|
|
specifications to enable access to the Web using spoken
|
|
interaction. This document is part of a set of requirements
|
|
studies for voice browsers, and provides details of the
|
|
requirements for reusable components for spoken dialogs.</p>
|
|
|
|
<h2 class="notoc">Status of this document</h2>
|
|
|
|
<p>This document describes the requirements for reusable dialog
|
|
components for spoken interaction, as a precursor to starting
|
|
work on specifications. Related requirement drafts are linked
|
|
from the <a href="/TR/voice-intro">introduction</a>. The
|
|
requirements are being released as working drafts but are not
|
|
intended to become proposed recommendations.</p>
|
|
|
|
<p>This specification is a Working Draft of the Voice Browser
|
|
working group for review by W3C members and other interested
|
|
parties. This is the first public version of this document. It is
|
|
a draft document and may be updated, replaced, or obsoleted by
|
|
other documents at any time. It is inappropriate to use W3C
|
|
Working Drafts as reference material or to cite them as other
|
|
than "work in progress".</p>
|
|
|
|
<p>Publication as a Working Draft does not imply endorsement by
|
|
the W3C membership, nor of members of the Voice Browser working
|
|
groups. This is still a draft document and may be updated,
|
|
replaced or obsoleted by other documents at any time. It is
|
|
inappropriate to cite W3C Working Drafts as other than "work in
|
|
progress."</p>
|
|
|
|
<p>This document has been produced as part of the <a
|
|
href="http://www.w3.org/Voice/">W3C Voice Browser 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/Voice/Group/">Voice Browser Working
|
|
Group</a> (W3C Members only). This document is for public review. Comments should be
|
|
sent to the public mailing list <<a
|
|
href="mailto:www-voice@w3.org">www-voice@w3.org</a>> (<a
|
|
href="http://lists.w3.org/Archives/Public/www-voice/">archive</a>).</p>
|
|
|
|
<p>A list of current W3C Recommendations and other technical
|
|
documents can be found at <a href="http://www.w3.org/TR">
|
|
http://www.w3.org/TR</a>.</p>
|
|
|
|
<p class="comment">NOTE: Text in an italicized teal font is a
|
|
comment.</p>
|
|
|
|
<p class="comment"> </p>
|
|
|
|
<h2>1. <a id="introduction" name="introduction">
|
|
</a>Introduction</h2>
|
|
|
|
<p>Reusable dialog components provide pre-packaged functionality
|
|
"out-of-the-box" that enables developers to quickly build
|
|
applications by providing standard default settings and behavior.
|
|
They shield developers from having to worry about many of the
|
|
intricacies associated with building a robust speech dialogue,
|
|
e.g., confidence score interpretation, error recovery mechanisms,
|
|
prompting, etc. This behavior can be customized by a developer if
|
|
necessary to provide application-specific prompts, vocabulary,
|
|
retry settings, etc.</p>
|
|
|
|
<p>The main goal of this subgroup is to develop a specification
|
|
for reusable dialog components within the context of an overall
|
|
specification for a markup language. The purpose of this document
|
|
is to establish a prioritized list of requirements for reusable
|
|
dialog components which any proposed markup language (or
|
|
extension thereof) should address.</p>
|
|
|
|
<h3>1.1. Scope</h3>
|
|
|
|
<p>Although desirable to standardize the interface to all dialog
|
|
components, this standardization is impractical for many dialogs.
|
|
In order to standardize the interface, one would have to
|
|
standardize the call flow, since the specifics of the call flow
|
|
determine the parameters that can be configured. If this document
|
|
attempts to standardize the call flow (and hence interface) for
|
|
more complex and debatable dialog components, the resulting
|
|
standard components are likely to contain only the lowest common
|
|
denominator of functionality and therefore be of limited
|
|
usefulness. Even the control flows for such common tasks as
|
|
acquiring telephone numbers and postal codes can differ from one
|
|
application and vendor to another. To preserve implementation
|
|
flexibility for more complex components, this document sorts
|
|
components into two categories -- those requiring only a return
|
|
semantics specification and those requiring both configuration
|
|
and return semantics specifications. This document also provides
|
|
some general requirements applicable to all components.</p>
|
|
|
|
<p>Note that the document provides no suggestions as to how these
|
|
components should be accessed (i.e. through a generic external
|
|
call interface vs. through specific markup elements vs. through
|
|
reference to a ML page in a standard library); rather, it is
|
|
important merely that the functionality described is packaged in
|
|
an easy-to-use fashion. There may consequently be some overlap
|
|
between components described here and sections of the Dialog
|
|
Requirements document. In general, the Dialog Requirements
|
|
document describes dialog <i>features</i>, while this document
|
|
describes <i>packaged/contained</i> dialogs. In practice this
|
|
distinction may disappear for some of the components described,
|
|
but there is no requirement that a component be implemented using
|
|
core features of the language itself.</p>
|
|
|
|
<h3>1.2. Organization</h3>
|
|
|
|
<p>The document is divided into the following sections:</p>
|
|
|
|
<ul>
|
|
<li><a href="#introduction">1. Introduction</a></li>
|
|
|
|
<li><a href="#general">2. General requirements</a></li>
|
|
|
|
<li><a href="#components">3. Component requirements</a></li>
|
|
|
|
<li><a href="#future">4. Future study</a></li>
|
|
|
|
<li><a href="#tables">5. Component tables</a></li>
|
|
</ul>
|
|
|
|
<p> </p>
|
|
|
|
<p> </p>
|
|
|
|
<h2>2. <a id="general" name="general"></a>General
|
|
requirements</h2>
|
|
|
|
<p>Requirements described in this section apply to all
|
|
components.</p>
|
|
|
|
<h3>2.1. Internationalization and localization</h3>
|
|
|
|
<h4>2.1.1. Support for localization (must specify)</h4>
|
|
|
|
<p>Components must provide support for different locales where
|
|
appropriate. For example, telephone number, postal code, and
|
|
address all vary in structure from one country to another.
|
|
"Support", in this case, can mean either configuration parameters
|
|
or simply multiple versions covering the range of locales where
|
|
usage is expected.</p>
|
|
|
|
<h4>2.1.2. Locale information (should specify)</h4>
|
|
|
|
<p>Locale information should be available from the application
|
|
context for use by components. Such information must conform to
|
|
existing ISO standards for countries and locales.</p>
|
|
|
|
<h3>2.2. Simultaneous activation of components (nice to
|
|
specify)</h3>
|
|
|
|
<p>For mixed initiative interactions, it would be nice to allow
|
|
multiple components to be active simultaneously during some
|
|
stages of the overall dialog. For example, possibly only the
|
|
initial grammars for multiple components would be active
|
|
simultaneously, with the grammar that matched the user's response
|
|
determining which component would handle the next
|
|
interaction.</p>
|
|
|
|
<h3>2.3. <a id="return" name="return"></a>Return values</h3>
|
|
|
|
<h4>2.3.1. NL Format (must specify)</h4>
|
|
|
|
<p>Return result(s) from a component must conform to the NL
|
|
format developed by the Natural Language subgroup.</p>
|
|
|
|
<h4>2.3.2. Keys and value formats (must specify)</h4>
|
|
|
|
<p>Note: the terminology in this requirement will be updated to
|
|
match that used by the Natural Language Semantics subgroup. For
|
|
now, the term "key" refers to a text label that a) does not vary
|
|
from one invocation of the component to another and b) has an
|
|
associated "value" that can vary from one invocation of the
|
|
component to another.</p>
|
|
|
|
<p>Each component must specify</p>
|
|
|
|
<ol>
|
|
<li>The semantics of standard return keys</li>
|
|
|
|
<li>The formats of the values associated with these keys</li>
|
|
</ol>
|
|
|
|
<h4>2.3.3. Implementation-specific information (must
|
|
specify)</h4>
|
|
|
|
<p>Components must also provide a means to return additional
|
|
implementation-specific keys and values.</p>
|
|
|
|
<h3>2.4. Error/exception handling (must specify)</h3>
|
|
|
|
<p>Components must be able to catch, pass on, or generate
|
|
exceptions. All exceptions passed on or generated must be
|
|
catchable by the calling application. Components are complete
|
|
dialogs and as such, to an extent appropriate for any given
|
|
component, are expected to appropriately handle many
|
|
reocgnizer-level conditions/exceptions rather than always passing
|
|
through such exceptions.</p>
|
|
|
|
<p class="comment">For example, simple user timeouts will most
|
|
commonly be captured and handled by the component, while an
|
|
exception signifying the inability to access a server needed by
|
|
the component would likely be partially handled within the
|
|
component and then passed on to the calling application. A user
|
|
hangup would likely just be passed on to the calling
|
|
application.</p>
|
|
|
|
<h3>2.5. Coordination between language and component features
|
|
(must specify)</h3>
|
|
|
|
<p>Components must have clearly published behavior for the cases
|
|
in which potential conflicts between "always active" language
|
|
features and those of the component can occur.</p>
|
|
|
|
<h3>2.6. Component composition (nice to specify)</h3>
|
|
|
|
<p>Where reasonable, components will be built using other
|
|
components to increase consistency in behavior across
|
|
components.</p>
|
|
|
|
<br />
|
|
<br />
|
|
<h2>3. <a id="components" name="components"></a>Component
|
|
requirements</h2>
|
|
|
|
<h3>3.1 Introduction</h3>
|
|
|
|
<p>One of the goals in providing packaged dialogs is to reduce
|
|
application developers' effort through appropriate abstraction.
|
|
Such abstraction can occur at many levels and can be implemented
|
|
in a number of different ways. For example, parameterized dialogs
|
|
can be implemented as markup elements with attributes and
|
|
sub-elements, as scripts built of markup elements and variables
|
|
(perhaps stored in a standard library of such dialogs), or as
|
|
native, precompiled, or otherwise non-markup language objects or
|
|
modules. Since this document does not in general address
|
|
implementation issues, there are no suggestions in this section
|
|
regarding the appropriateness of the dialogs below being
|
|
implemented in one way over another.</p>
|
|
|
|
<p>The components in this section are presented in that context.
|
|
They represent actual dialogs (or dialog templates) and not
|
|
dialog features (like help prompts or the <i>ability</i> to
|
|
construct confirmation dialogs).</p>
|
|
|
|
<p> </p>
|
|
|
|
<h3>3.2. <a id="component_organization"
|
|
name="component_organization"></a>Organization</h3>
|
|
|
|
<p>The components in this section can be categorized along 3
|
|
dimensions:</p>
|
|
|
|
<dl>
|
|
<dt>Return only vs. Configuration/Return</dt>
|
|
|
|
<dd>For all components, the return semantics will be specified
|
|
(see <a href="#return">Section 2.3</a>). However, some components
|
|
will have dialog flows that vary considerably by vendor and
|
|
application. Since the dialog structure determines the parameters
|
|
that could possibly be configured, it is infeasible and
|
|
restrictive to specify the list of component-specific
|
|
configuration parameters for such components. Therefore, for some
|
|
components <i>only</i> the return semantics will be specified;
|
|
for others, both the configuration parameters and return
|
|
semantics will be specified.</dd>
|
|
|
|
<dt>Specification priority</dt>
|
|
|
|
<dd>Must specify, should specify, and nice to specify indicate
|
|
the order in which components will be considered for inclusion in
|
|
the specification document.</dd>
|
|
|
|
<dt>Task vs. template</dt>
|
|
|
|
<dd>Task components actually obtain some piece or pieces of
|
|
information. Template components merely provide some call flow
|
|
framework. Although task components most likely will be
|
|
configured, they will operate as-is. Template components will not
|
|
work without configuration.</dd>
|
|
</dl>
|
|
|
|
<p>This section is sorted first along Config/Return vs. Return
|
|
only, then along Specification priority. Tables containing
|
|
alternate sorting orders can be found in <a href="#tables">
|
|
Section 5</a>.</p>
|
|
|
|
<p> </p>
|
|
|
|
<h3>3.3. Components requiring configuration and return
|
|
specifications</h3>
|
|
|
|
<p>Components in this section are considered to have control
|
|
flows that will not change significantly between application or
|
|
vendor. For these components, both component-specific
|
|
configurable parameters and the return semantics (see <a
|
|
href="#return">Section 2.3</a>) must be specified. In addition,
|
|
any general configurable parameters required by <a
|
|
href="#general">Section 2</a> must still be specified.</p>
|
|
|
|
<h4>3.3.1. <a id="yes_no" name="yes_no"></a>Yes/No (must specify,
|
|
task)</h4>
|
|
|
|
<p>This component is intended to be used as a simple confirmation
|
|
and will prompt the user with a question or statement. The
|
|
grammar will handle a variety of affirmative and negative
|
|
responses and return a "yes" or "no", respectively.</p>
|
|
|
|
<p>Possible configurable parameters are:</p>
|
|
|
|
<ol>
|
|
<li>Initial prompt (must specify)</li>
|
|
|
|
<li>Additional affirmative response grammar (should specify)</li>
|
|
|
|
<li>Additional negative response grammar (should specify)</li>
|
|
</ol>
|
|
|
|
<p>The component is intended to be used as a simple
|
|
confirmation.</p>
|
|
|
|
<h4>3.3.2. <a id="natural_numbers" name="natural_numbers">
|
|
</a>Natural numbers (must specify, task)</h4>
|
|
|
|
<p>This component will prompt for and recognize natural numbers.
|
|
As an example, this could be useful in applications where a
|
|
certain number of items are being ordered or processed. This
|
|
component should be able to recognize natural numbers between 0
|
|
and some large number (e.g. 99,999,999).</p>
|
|
|
|
<p>The component may also have the following requirements:</p>
|
|
|
|
<dl>
|
|
<dt>Range restriction (should specify)</dt>
|
|
|
|
<dd>Allow for a range restriction to be set on recognized numbers
|
|
in order to improve recognition accuracy.</dd>
|
|
|
|
<dt>N-best list (should specify)</dt>
|
|
|
|
<dd>Be capable of returning an n-best list of recognized numbers
|
|
so that application-level filtering/restriction can be
|
|
applied.</dd>
|
|
</dl>
|
|
|
|
<h4>3.3.3. <a id="simple_digit" name="simple_digit"></a>Simple
|
|
digit string (must specify, task)</h4>
|
|
|
|
<p>This component will prompt for and recognize a fixed-length
|
|
string of digits.</p>
|
|
|
|
<p>Possible configurable parameters are:</p>
|
|
|
|
<ol>
|
|
<li>Initial prompt (must specify)</li>
|
|
|
|
<li>Expected length of digit string (must specify)</li>
|
|
|
|
<li>List of expected digit string lengths (nice to specify)</li>
|
|
</ol>
|
|
|
|
<p>The component may also have the following requirements:</p>
|
|
|
|
<dl>
|
|
<dt>N-best list (should specify)</dt>
|
|
|
|
<dd>Be capable of returning an n-best list of recognized digit
|
|
strings so that application-level filtering/restriction can be
|
|
applied.</dd>
|
|
|
|
<dt>Mixed digits and natural numbers (should specify)</dt>
|
|
|
|
<dd>Supports strings that mix both digits and naturally-spoken
|
|
numbers, eg "one two three four seven thousand".</dd>
|
|
|
|
<dt>Validation options (should specify)</dt>
|
|
|
|
<dd>The component will optionally do matching against
|
|
|
|
<ul>
|
|
<li>a constrained list,</li>
|
|
|
|
<li>a regular expression, and/or</li>
|
|
|
|
<li>a database query</li>
|
|
</ul>
|
|
|
|
<blockquote>
|
|
<p> </p>
|
|
</blockquote>
|
|
</dd>
|
|
</dl>
|
|
|
|
<h4>3.3.4. <a id="full_date" name="full_date"></a>Fully-specified
|
|
date (must specify, task)</h4>
|
|
|
|
<p>This component will collect a fully-specified date. Any
|
|
ambiguity in the user's initial statement of the date will be
|
|
cleared up by the component without benefit of
|
|
application-maintained context. For example, the component may
|
|
use additional prompting to disambiguate. The component will
|
|
return a fully-specified date. If unable to return a
|
|
fully-specified date, the component will generate an error.</p>
|
|
|
|
<p>Possible configurable parameters are:</p>
|
|
|
|
<ol>
|
|
<li>Initial prompt (must specify)</li>
|
|
|
|
<li>Calendar system - eg Gregorian, Islamic, Jewish (nice to
|
|
specify)</li>
|
|
</ol>
|
|
|
|
<h4>3.3.5. <a id="partial_date" name="partial_date">
|
|
</a>Partially-specified date (should specify, task)</h4>
|
|
|
|
<p>This component will collect a date. Any ambiguity in the
|
|
user's initial statement of the date will be cleared up by the
|
|
component without benefit of application-maintained context. For
|
|
example, the component may use additional prompting to
|
|
disambiguate. The component will then return as much of the date
|
|
as it has obtained. Note that this means the component may return
|
|
either a fully-specified date or a partially-specified date.</p>
|
|
|
|
<p>Possible configurable parameters are:</p>
|
|
|
|
<ol>
|
|
<li>Initial prompt (must specify)</li>
|
|
|
|
<li>Boolean flag indicating whether or not to disambiguate a
|
|
partially-specified date (should specify)</li>
|
|
|
|
<li>Calendar system - eg Gregorian, Islamic, Jewish (nice to
|
|
specify)</li>
|
|
</ol>
|
|
|
|
<h4>3.3.6. <a id="error_template" name="error_template">
|
|
</a>Simple error-recovery template dialog (should specify,
|
|
template)</h4>
|
|
|
|
<p>This component would provide only simple error detection and
|
|
reprompting.</p>
|
|
|
|
<p>Possible configurable parameters are:</p>
|
|
|
|
<ol>
|
|
<li>Initial prompt (must specify)</li>
|
|
|
|
<li>Grammar (must specify)</li>
|
|
|
|
<li>Replacement for default error prompts (should specify)</li>
|
|
</ol>
|
|
|
|
<h4>3.3.7. <a id="simple_alpha" name="simple_alpha"></a>Simple
|
|
alpha string (should specify, task)</h4>
|
|
|
|
<p>This component will prompt for and recognize a fixed-length
|
|
string of letters.</p>
|
|
|
|
<p>Possible configurable parameters are:</p>
|
|
|
|
<ol>
|
|
<li>Initial prompt (must specify)</li>
|
|
|
|
<li>Expected length of alpha string (must specify)</li>
|
|
|
|
<li>List of expected alpha string lengths (nice to specify)</li>
|
|
</ol>
|
|
|
|
<p>The component may also have the following requirements:</p>
|
|
|
|
<dl>
|
|
<dt>N-best list (should specify)</dt>
|
|
|
|
<dd>Be capable of returning an n-best list of recognized alpha
|
|
strings so that application-level filtering/restriction can be
|
|
applied.</dd>
|
|
|
|
<dt>Validation options (should specify)</dt>
|
|
|
|
<dd>The component will optionally do matching against
|
|
|
|
<ul>
|
|
<li>a constrained list,</li>
|
|
|
|
<li>a regular expression, and/or</li>
|
|
|
|
<li>a database query</li>
|
|
</ul>
|
|
|
|
<blockquote>
|
|
<p> </p>
|
|
</blockquote>
|
|
</dd>
|
|
</dl>
|
|
|
|
<h4>3.3.8. <a id="simple_alphanumeric"
|
|
name="simple_alphanumeric"></a>Simple alphanumeric string (should
|
|
specify, task)</h4>
|
|
|
|
<p>This component will prompt for and recognize a fixed-length
|
|
string of letters and digits.</p>
|
|
|
|
<p>Possible configurable parameters are:</p>
|
|
|
|
<ol>
|
|
<li>Initial prompt (must specify)</li>
|
|
|
|
<li>Expected length of alphanumeric string (must specify)</li>
|
|
|
|
<li>List of expected alphanumeric string lengths (nice to
|
|
specify)</li>
|
|
</ol>
|
|
|
|
<p>The component may also have the following requirements:</p>
|
|
|
|
<dl>
|
|
<dt>N-best list (should specify)</dt>
|
|
|
|
<dd>Be capable of returning an n-best list of recognized
|
|
alphanumeric strings so that application-level
|
|
filtering/restriction can be applied.</dd>
|
|
|
|
<dt>Mixed alphadigits and natural numbers (should specify)</dt>
|
|
|
|
<dd>Supports strings that mix both alphadigits and
|
|
naturally-spoken numbers, eg "a b three four seven
|
|
thousand".</dd>
|
|
|
|
<dt>Validation options (should specify)</dt>
|
|
|
|
<dd>The component will optionally do matching against
|
|
|
|
<ul>
|
|
<li>a constrained list,</li>
|
|
|
|
<li>a regular expression, and/or</li>
|
|
|
|
<li>a database query</li>
|
|
</ul>
|
|
|
|
<blockquote>
|
|
<p> </p>
|
|
</blockquote>
|
|
</dd>
|
|
</dl>
|
|
|
|
<h3>3.4. Components requiring only a return semantics
|
|
specification</h3>
|
|
|
|
<p>Components in this section are considered to have dialog flows
|
|
that vary considerably by application. Thus, only the component's
|
|
return semantics will be specified (as per <a href="#return">
|
|
Section 2.3</a>). Despite the foregoing sentence, any general
|
|
configurable parameters required by <a href="#general">Section
|
|
2</a> must still be specified.</p>
|
|
|
|
<h4>3.4.1. <a id="time" name="time"></a>Time (must specify,
|
|
task)</h4>
|
|
|
|
<p>The Time component will provide generic acquisition of clock
|
|
times -- for example, "three forty-five AM" or "fourteen
|
|
twenty-three". If the time is ambiguous (hour < 13 and
|
|
before-/after-noon designation not provided), the component
|
|
should conduct additional dialog as needed to clarify. Although
|
|
time zone specifiers must be recognized if spoken by the user,
|
|
they are not required of the user.</p>
|
|
|
|
<h4>3.4.2. <a id="menu" name="menu"></a>Menu (must specify,
|
|
template)</h4>
|
|
|
|
<p>This component plays a prompt offering the caller a menu of
|
|
items from which she may select a single item and then returns an
|
|
identifier corresponding to the chosen item.</p>
|
|
|
|
<h4>3.4.3. <a id="currency" name="currency"></a>Currency (must
|
|
specify, task)</h4>
|
|
|
|
<p>The purpose of this component is to obtain a money amount. The
|
|
grammar will accept any common means of specifying amounts in the
|
|
currency. For example, US Currency would allow "three dollars and
|
|
twenty five cents" while German currency might allow "zwei Mark
|
|
fuenfzig".</p>
|
|
|
|
<h4>3.4.4. <a id="context_date" name="context_date">
|
|
</a>Context-compensating date (should specify, task)</h4>
|
|
|
|
<p>This component will collect a date. Any ambiguity in the
|
|
user's initial statement of the date will be cleared up with the
|
|
benefit of application-maintained context. This component will
|
|
then return as much of the date as it has obtained. Note that
|
|
this means the component may return either a fully-specified or
|
|
partially-specified date.</p>
|
|
|
|
<h4>3.4.5. <a id="telephone" name="telephone"></a>Telephone
|
|
number (should specify, task)</h4>
|
|
|
|
<p>This component will encapsulate the task of acquiring a
|
|
telephone number. If a single confirmed number is desired, the
|
|
component will confirm the number and perform error-recovery, if
|
|
necessary. Otherwise, it should provide an n-best list of
|
|
recognized telephone numbers that the application can filter.</p>
|
|
|
|
<h4>3.4.6. <a id="sectioned_digit" name="sectioned_digit">
|
|
</a>Sectioned digit string (should specify, task)</h4>
|
|
|
|
<p>This component will prompt for and recognize digit-strings
|
|
consisting of sections, such as might be found in a credit card
|
|
number, social services identification number, and the like.</p>
|
|
|
|
<p>The component may also have the following requirements:</p>
|
|
|
|
<dl>
|
|
<dt>Multiple sectionings (should specify)</dt>
|
|
|
|
<dd>Allow for multiple sectionings of the string to be
|
|
configured, where each sectioning
|
|
|
|
<ul>
|
|
<li>Allows the number of sections to be configured.</li>
|
|
|
|
<li>Allows the number of digits in each section to be
|
|
configured.</li>
|
|
</ul>
|
|
|
|
Note the implication that different-length strings may be
|
|
allowed.</dd>
|
|
|
|
<dt>N-best list (should specify)</dt>
|
|
|
|
<dd>Be capable of returning an n-best list of recognized digit
|
|
strings so that application-level filtering/restriction can be
|
|
applied.</dd>
|
|
|
|
<dt>Mixed digits and natural numbers (should specify)</dt>
|
|
|
|
<dd>Supports sections that mix both digits and naturally-spoken
|
|
numbers, eg "one two three four seven thousand".</dd>
|
|
|
|
<dt>Validation options (should specify)</dt>
|
|
|
|
<dd>The component will optionally do matching against
|
|
|
|
<ul>
|
|
<li>a constrained list,</li>
|
|
|
|
<li>a regular expression, and/or</li>
|
|
|
|
<li>a database query</li>
|
|
</ul>
|
|
</dd>
|
|
|
|
<dt> </dt>
|
|
</dl>
|
|
|
|
<h4>3.4.7. <a id="sectioned_alphanumeric"
|
|
name="sectioned_alphanumeric"></a>Sectioned alphanumeric string
|
|
(should specify, task)</h4>
|
|
|
|
<p>This component will prompt for and recognize alphanumeric
|
|
strings consisting of sections, such as might be found in a
|
|
product code, user identifier, automobile license place, etc.</p>
|
|
|
|
<p>The component may also have the following requirements:</p>
|
|
|
|
<dl>
|
|
<dt>Multiple sectionings (should specify)</dt>
|
|
|
|
<dd>Allow for multiple sectionings of the string to be
|
|
configured, where each sectioning
|
|
|
|
<ul>
|
|
<li>Allows the number of sections to be configured.</li>
|
|
|
|
<li>Allows the number of alphadigits in each section to be
|
|
configured.</li>
|
|
</ul>
|
|
|
|
Note the implication that different-length strings may be
|
|
allowed.</dd>
|
|
|
|
<dt>N-best list (should specify)</dt>
|
|
|
|
<dd>Be capable of returning an n-best list of recognized
|
|
alphadigit strings so that application-level
|
|
filtering/restriction can be applied.</dd>
|
|
|
|
<dt>Mixed alphadigits and natural numbers (should specify)</dt>
|
|
|
|
<dd>Supports sections that mix both alphadigits and
|
|
naturally-spoken numbers, eg "a b three four seven
|
|
thousand".</dd>
|
|
|
|
<dt>Validation options (should specify)</dt>
|
|
|
|
<dd>The component will optionally do matching against
|
|
|
|
<ul>
|
|
<li>a constrained list,</li>
|
|
|
|
<li>a regular expression, and/or</li>
|
|
|
|
<li>a database query</li>
|
|
</ul>
|
|
|
|
<blockquote>
|
|
<p> </p>
|
|
</blockquote>
|
|
</dd>
|
|
</dl>
|
|
|
|
<h4>3.4.8. <a id="confirm_and_correct"
|
|
name="confirm_and_correct"></a>Confirmation and correction dialog
|
|
(should specify, template)</h4>
|
|
|
|
<p>This component would be responsible for confirming one or more
|
|
items of information given by the user. If the user indicates
|
|
that one or more items of information are wrong, this component
|
|
could walk the user through the process of correcting them by
|
|
calling other pages and/or components.</p>
|
|
|
|
<h4>3.4.9. <a id="browsable_selection"
|
|
name="browsable_selection"></a>Browsable selection list (should
|
|
specify, template)</h4>
|
|
|
|
<p>This component allows the caller to hear items in a list in
|
|
sequence and optionally navigate through the list. By default,
|
|
the list would play prompts associated with items, one after
|
|
another. Note that any item may be selected at any time by
|
|
speaking the appropriate grammar entry. In addition, the
|
|
component allows the user to select an item from the list. The
|
|
component then returns the index of the selected item.</p>
|
|
|
|
<h4>3.4.10. <a id="browsable_action" name="browsable_action">
|
|
</a>Browsable action list (should specify, template)</h4>
|
|
|
|
<p>This component allows the caller to hear items in a list in
|
|
sequence and optionally navigate through the list. By default,
|
|
the list would play prompts associated with items, one after
|
|
another. Note that any item may be selected at any time by
|
|
speaking the appropriate grammar entry. In addition, the
|
|
component would allow the user to say application-specific
|
|
commands that cause corresponding event handlers to be
|
|
executed.</p>
|
|
|
|
<h4>3.4.11. <a id="postal_code" name="postal_code"></a>Postal
|
|
code (should specify, task)</h4>
|
|
|
|
<p>This component will ask for and recognize a valid postal
|
|
code.</p>
|
|
|
|
<h4>3.4.12. <a id="spelled_name" name="spelled_name"></a>Spelled
|
|
name (should specify, task)</h4>
|
|
|
|
<p>This component will obtain the correct spelling of one or more
|
|
names (for example, a given name, middle name or initial, and
|
|
family name). The names may be obtained individually and
|
|
confirmed together, possibly with some error correction
|
|
dialog.</p>
|
|
|
|
<h4>3.4.13. <a id="spoken_spelled_name"
|
|
name="spoken_spelled_name"></a>Spoken and spelled name (should
|
|
specify, task)</h4>
|
|
|
|
<p>This component will prompt for and obtain a spoken name(s),
|
|
optionally followed by the spelling of the name(s). As with the
|
|
Spelled name component, this component may obtain the names
|
|
separately and confirm them together, possibly with some error
|
|
correction dialog.</p>
|
|
|
|
<h4>3.4.14. <a id="credit_card" name="credit_card"></a>Credit
|
|
card information (should specify, task)</h4>
|
|
|
|
<p>This component will encapsulate the task of acquiring credit
|
|
card information from a caller. It will collect the card type,
|
|
card number, and expiration date (month and year). It must
|
|
support a wide variety of standard cards (Visa, MC, AMEX, Diner's
|
|
club, Discover, etc.)</p>
|
|
|
|
<p>The component may also have the following requirements:</p>
|
|
|
|
<dl>
|
|
<dt>Validation (should specify)</dt>
|
|
|
|
<dd>The component will verify that the card number is a valid
|
|
number for the type of card.</dd>
|
|
|
|
<dt>Cardholder's name (should specify)</dt>
|
|
|
|
<dd>The component will optionally acquire the cardholder's
|
|
spelled name.</dd>
|
|
</dl>
|
|
|
|
<h4>3.4.15. <a id="email_address" name="email_address"></a>Email
|
|
address(should specify, task)</h4>
|
|
|
|
<p>This component will obtain the user's email address.</p>
|
|
|
|
<h4>3.4.16. <a id="time_range" name="time_range"></a>Time range
|
|
(should specify, task)</h4>
|
|
|
|
<p>This component will provide generic acquisition of clock time
|
|
ranges -- for example, "between one PM and three PM". If either
|
|
or both of the times are ambiguous (hour < 13 and
|
|
before-/after-noon designation not provided), the component
|
|
should conduct additional dialog as needed to clarify.</p>
|
|
|
|
<h4>3.4.17. <a id="duration" name="duration"></a>Duration (should
|
|
specify, task)</h4>
|
|
|
|
<p>This component will acquire a duration. The component will be
|
|
able to accept any common duration unit (seconds, minutes, etc.)
|
|
and will conduct additional dialog as necessary to resolve the
|
|
units if ambiguous.</p>
|
|
|
|
<h4>3.4.18. <a id="url" name="url"></a>URL (should specify,
|
|
task)</h4>
|
|
|
|
<p>This component will acquire Uniform Resource Locators as
|
|
described in IETF RFC XXXX.</p>
|
|
|
|
<h4>3.4.19. <a id="address" name="address"></a>Address (nice to
|
|
specify, task)</h4>
|
|
|
|
<p>This component will obtain the physical or mailing address of
|
|
the caller.</p>
|
|
|
|
<h4>3.4.20. <a id="multiple_choice" name="multiple_choice">
|
|
</a>Multiple choice selections (nice to specify, template)</h4>
|
|
|
|
<p>This component will allow a user to select one or more items
|
|
from a set of valid options.</p>
|
|
|
|
<h4>3.4.21. <a id="non-fixed_alphanumeric"
|
|
name="non-fixed_alphanumeric"></a>Non-fixed alphanumeric string
|
|
(nice to specify, task)</h4>
|
|
|
|
<p>This component acquires an arbitrary-length sequence of
|
|
letters and digits.</p>
|
|
|
|
<p> </p>
|
|
|
|
<p> </p>
|
|
|
|
<h2>4. <a id="future" name="future"></a>Future study</h2>
|
|
|
|
<p>Items in this section are ones that will be considered for
|
|
future study. Although not a part of the requirements document
|
|
per se, they are included here to inform the reader of other
|
|
topics that have been discussed and consciously postponed for
|
|
future study.</p>
|
|
|
|
<h3>4.1. Optional initial grammar embedding</h3>
|
|
|
|
<p>Components may optionally allow the initial grammar to be
|
|
embedded within an extended initial grammar provided by the
|
|
developer.</p>
|
|
|
|
<p><span class="comment">An example of this might occur in an
|
|
implementation of the Date component. In this hypothetical
|
|
implementation, there is a single initial "date" grammar that
|
|
will be used to recognize the user's first utterance. This
|
|
particular implementation is written under the assumption that
|
|
the user will be asked to give the complete date (as opposed to
|
|
asking for the day, the month, and the year separately). The
|
|
developer may wish, then, to change the initial grammar to be
|
|
something like the following:</span></p>
|
|
|
|
<blockquote>
|
|
<p><span class="comment">I would like to book an appointment for
|
|
<date></span></p>
|
|
</blockquote>
|
|
|
|
<p><span class="comment">This future study item is listed as
|
|
optional because it presumes that the dialog for the component
|
|
will prompt for and expect all of its data items in the first
|
|
interaction with the user. Removing the optionality of this
|
|
requirement would unneccesarily restrict the implementation of
|
|
the dialog.</span></p>
|
|
|
|
<h3>4.2. Optional confirmation</h3>
|
|
|
|
<p>Components may optionally perform a final confirmation of any
|
|
data items acquired. The developer can specify how the
|
|
confirmation prompt is to be built from the result.</p>
|
|
|
|
<p class="comment">This requirement is listed as optional because
|
|
it presumes there will be a single confirmation prompt. Making
|
|
this requirement non-optional would unneccessarily restrict the
|
|
implementation of the dialog.</p>
|
|
|
|
<h3>4.3. Component -- Give help</h3>
|
|
|
|
<p>This component will prompt for an online help service.</p>
|
|
|
|
<p>Possible configurable parameters are:</p>
|
|
|
|
<ol>
|
|
<li>Initial prompt (must specify)</li>
|
|
|
|
<li>List of help items (must specify)</li>
|
|
</ol>
|
|
|
|
<h3>4.4. Component -- Transfer to agent</h3>
|
|
|
|
<p>This component will pass the phone call to an operator.</p>
|
|
|
|
<p>Possible configurable parameters are:</p>
|
|
|
|
<ol>
|
|
<li>Initial prompt (must specify)</li>
|
|
</ol>
|
|
|
|
<h3>4.5. Component -- Physical measurements</h3>
|
|
|
|
<p>This component will acquire a physical measurement (eg. "five
|
|
pounds, 4 ounces" or "three light years").</p>
|
|
|
|
<h3>4.6. Component -- Ordinals</h3>
|
|
|
|
<p>This component will collect an ordinal number.</p>
|
|
|
|
<p class="comment">Note: this may be challenging in Japanese
|
|
where the ordinal used depends on the object being ordered.</p>
|
|
|
|
<p> </p>
|
|
|
|
<p> </p>
|
|
|
|
<h2>5. <a id="tables" name="tables"></a>Component tables</h2>
|
|
|
|
<p>These tables list all the components using various different
|
|
sorting orders for convenience. For explanations of the three
|
|
dimensions along which components are organized, see <a
|
|
href="#component_organization">Section 3.2</a>.</p>
|
|
|
|
<h3>5.1. Alphabetical</h3>
|
|
|
|
<table width="85%" border="1" cellspacing="0" cellpadding="5">
|
|
<tr>
|
|
<td><i><b>Component</b></i></td>
|
|
<td><i><b>Specification priority</b></i></td>
|
|
<td><i><b>Specification level</b></i></td>
|
|
<td><i><b>Task vs. Template</b></i></td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#address">Address</a></td>
|
|
<td>Nice to</td>
|
|
<td>Return only</td>
|
|
<td>Task</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#email_address">Address, email</a></td>
|
|
<td>Should</td>
|
|
<td>Return only</td>
|
|
<td>Task</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#simple_alpha">Alpha string, simple</a></td>
|
|
<td>Should</td>
|
|
<td>Configure & Return</td>
|
|
<td>Task</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#non-fixed_alphanumeric">Alphanumeric string,
|
|
non-fixed</a></td>
|
|
<td>Nice to</td>
|
|
<td>Return only</td>
|
|
<td>Task</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#sectioned_alphanumeric">Alphanumeric string,
|
|
sectioned</a></td>
|
|
<td>Should</td>
|
|
<td>Return only</td>
|
|
<td>Task</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#simple_alphanumeric">Alphanumeric string,
|
|
simple</a></td>
|
|
<td>Should</td>
|
|
<td>Configure & Return</td>
|
|
<td>Task</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#browsable_action">Browsable action list</a></td>
|
|
<td>Should</td>
|
|
<td>Return only</td>
|
|
<td>Template</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#browsable_selection">Browsable selection
|
|
list</a></td>
|
|
<td>Should</td>
|
|
<td>Return only</td>
|
|
<td>Template</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#credit_card">Credit card information</a></td>
|
|
<td>Should</td>
|
|
<td>Return only</td>
|
|
<td>Task</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#confirm_and_correct">Confirmation & correction
|
|
dialog</a></td>
|
|
<td>Should</td>
|
|
<td>Return only</td>
|
|
<td>Template</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#currency">Currency</a></td>
|
|
<td>Must</td>
|
|
<td>Return only</td>
|
|
<td>Task</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#context_date">Date, context-compensating</a></td>
|
|
<td>Should</td>
|
|
<td>Return only</td>
|
|
<td>Task</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#full_date">Date, fully-specified</a></td>
|
|
<td>Must</td>
|
|
<td>Configure & Return</td>
|
|
<td>Task</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#partial_date">Date, partially-specified</a></td>
|
|
<td>Should</td>
|
|
<td>Configure & Return</td>
|
|
<td>Task</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#sectioned_digit">Digit string, sectioned</a></td>
|
|
<td>Should</td>
|
|
<td>Return only</td>
|
|
<td>Task</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#simple_digit">Digit string, simple</a></td>
|
|
<td>Must</td>
|
|
<td>Configure & Return</td>
|
|
<td>Task</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#duration">Duration</a></td>
|
|
<td>Should</td>
|
|
<td>Return only</td>
|
|
<td>Task</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#error_template">Error-recovery dialog,
|
|
simple</a></td>
|
|
<td>Should</td>
|
|
<td>Configure & Return</td>
|
|
<td>Template</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#menu">Menu</a></td>
|
|
<td>Must</td>
|
|
<td>Return only</td>
|
|
<td>Template</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#multiple_choice">Multiple choice
|
|
selections</a></td>
|
|
<td>Nice to</td>
|
|
<td>Return only</td>
|
|
<td>Template</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#spelled_name">Name, spelled</a></td>
|
|
<td>Should</td>
|
|
<td>Return only</td>
|
|
<td>Task</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#spoken_spelled_name">Name, spoken &
|
|
spelled</a></td>
|
|
<td>Should</td>
|
|
<td>Return only</td>
|
|
<td>Task</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#natural_numbers">Natural numbers</a></td>
|
|
<td>Must</td>
|
|
<td>Configure & Return</td>
|
|
<td>Task</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#postal_code">Postal code</a></td>
|
|
<td>Should</td>
|
|
<td>Return only</td>
|
|
<td>Task</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#telephone">Telephone number</a></td>
|
|
<td>Should</td>
|
|
<td>Return only</td>
|
|
<td>Task</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#time">Time</a></td>
|
|
<td>Must</td>
|
|
<td>Return only</td>
|
|
<td>Task</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#time_range">Time range</a></td>
|
|
<td>Should</td>
|
|
<td>Return only</td>
|
|
<td>Task</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#url">URL</a></td>
|
|
<td>Should</td>
|
|
<td>Return only</td>
|
|
<td>Task</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#yes_no">Yes/No</a></td>
|
|
<td>Must</td>
|
|
<td>Configure & Return</td>
|
|
<td>Task</td>
|
|
</tr>
|
|
</table>
|
|
|
|
<h3>5.2. Priority, then Config/Return vs. Return only, then Task
|
|
vs. Template</h3>
|
|
|
|
<table width="85%" border="1" cellspacing="0" cellpadding="5">
|
|
<tr>
|
|
<td><i><b>Component</b></i></td>
|
|
<td><i><b>Specification priority</b></i></td>
|
|
<td><i><b>Specification level</b></i></td>
|
|
<td><i><b>Task vs. Template</b></i></td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#yes_no">Yes/No</a></td>
|
|
<td>Must</td>
|
|
<td>Configure & Return</td>
|
|
<td>Task</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#natural_numbers">Natural numbers</a></td>
|
|
<td>Must</td>
|
|
<td>Configure & Return</td>
|
|
<td>Task</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#simple_digit">Simple digit string</a></td>
|
|
<td>Must</td>
|
|
<td>Configure & Return</td>
|
|
<td>Task</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#full_date">Fully-specified date</a></td>
|
|
<td>Must</td>
|
|
<td>Configure & Return</td>
|
|
<td>Task</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#time">Time</a></td>
|
|
<td>Must</td>
|
|
<td>Return only</td>
|
|
<td>Task</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#currency">Currency</a></td>
|
|
<td>Must</td>
|
|
<td>Return only</td>
|
|
<td>Task</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#menu">Menu</a></td>
|
|
<td>Must</td>
|
|
<td>Return only</td>
|
|
<td>Template</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#partial_date">Partially-specified date</a></td>
|
|
<td>Should</td>
|
|
<td>Configure & Return</td>
|
|
<td>Task</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#simple_alpha">Simple alpha string</a></td>
|
|
<td>Should</td>
|
|
<td>Configure & Return</td>
|
|
<td>Task</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#simple_alphanumeric">Simple alphanumeric
|
|
string</a></td>
|
|
<td>Should</td>
|
|
<td>Configure & Return</td>
|
|
<td>Task</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#error_template">Simple error-recovery
|
|
dialog</a></td>
|
|
<td>Should</td>
|
|
<td>Configure & Return</td>
|
|
<td>Template</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#context_date">Context-compensating date</a></td>
|
|
<td>Should</td>
|
|
<td>Return only</td>
|
|
<td>Task</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#telephone">Telephone number</a></td>
|
|
<td>Should</td>
|
|
<td>Return only</td>
|
|
<td>Task</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#sectioned_digit">Sectioned digit string</a></td>
|
|
<td>Should</td>
|
|
<td>Return only</td>
|
|
<td>Task</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#sectioned_alphanumeric">Sectioned alphanumeric
|
|
string</a></td>
|
|
<td>Should</td>
|
|
<td>Return only</td>
|
|
<td>Task</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#postal_code">Postal code</a></td>
|
|
<td>Should</td>
|
|
<td>Return only</td>
|
|
<td>Task</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#spelled_name">Spelled name</a></td>
|
|
<td>Should</td>
|
|
<td>Return only</td>
|
|
<td>Task</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#spoken_spelled_name">Spoken & spelled
|
|
name</a></td>
|
|
<td>Should</td>
|
|
<td>Return only</td>
|
|
<td>Task</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#credit_card">Credit card information</a></td>
|
|
<td>Should</td>
|
|
<td>Return only</td>
|
|
<td>Task</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#email_address">Email address</a></td>
|
|
<td>Should</td>
|
|
<td>Return only</td>
|
|
<td>Task</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#time_range">Time range</a></td>
|
|
<td>Should</td>
|
|
<td>Return only</td>
|
|
<td>Task</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#duration">Duration</a></td>
|
|
<td>Should</td>
|
|
<td>Return only</td>
|
|
<td>Task</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#url">URL</a></td>
|
|
<td>Should</td>
|
|
<td>Return only</td>
|
|
<td>Task</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#confirm_and_correct">Confirmation & correction
|
|
dialog</a></td>
|
|
<td>Should</td>
|
|
<td>Return only</td>
|
|
<td>Template</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#browsable_selection">Browsable selection
|
|
list</a></td>
|
|
<td>Should</td>
|
|
<td>Return only</td>
|
|
<td>Template</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#browsable_action">Browsable action list</a></td>
|
|
<td>Should</td>
|
|
<td>Return only</td>
|
|
<td>Template</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#address">Address</a></td>
|
|
<td>Nice to</td>
|
|
<td>Return only</td>
|
|
<td>Task</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#non-fixed_alphanumeric">Non-fixed alphanumeric
|
|
string</a></td>
|
|
<td>Nice to</td>
|
|
<td>Return only</td>
|
|
<td>Task</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#multiple_choice">Multiple choice
|
|
selections</a></td>
|
|
<td>Nice to</td>
|
|
<td>Return only</td>
|
|
<td>Template</td>
|
|
</tr>
|
|
</table>
|
|
|
|
<h2>Acknowledgements</h2>
|
|
|
|
<p>The editor wishes to thank the members of the resuable dialog
|
|
components subgroup for their help in preparing this draft:</p>
|
|
|
|
<blockquote>
|
|
<p>Michael Brown (Lucent/Bell Labs)<br />
|
|
Daniel C. Burnett (Nuance)<br />
|
|
Deborah Dahl (Unisys)<br />
|
|
Carolina di Cristo (CSELT)<br />
|
|
Linda Dorrian (Productivity Works)<br />
|
|
Andrew Hunt (SpeechWorks)<br />
|
|
Robert Keiller (Canon)<br />
|
|
Andreas Kellner (Philips)<br />
|
|
David Ladd (Motorola)<br />
|
|
Jens Marschner (Philips)<br />
|
|
Stephen Potter (Entropic)<br />
|
|
Dave Raggett (W3C/HP)<br />
|
|
Ramesh Sarukkai (Yahoo Inc.)<br />
|
|
Frank Scahill (BT)<br />
|
|
Kuansan Wang (Microsoft)</p>
|
|
</blockquote>
|
|
</body>
|
|
</html>
|
|
|