WD-reusable-dialog-reqs-20000426 42.3 KB

Raw Blame History Permalink

<!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>&#160;</dt>

<dt>Editor:</dt>

<dd>Daniel C. Burnett &lt;<a
href="mailto:burnett@nuance.com">burnett@nuance.com</a>&gt;</dd>
</dl>

<p class="copyright"><a
href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">
Copyright</a>&#169; 2000 <a href="http://www.w3.org/"><abbr
title="World Wide Web Consortium">W3C</abbr></a><sup>&#174;</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 &lt;<a
href="mailto:www-voice@w3.org">www-voice@w3.org</a>&gt; (<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">&#160;</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>&#160;</p>

<p>&#160;</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>&#160;</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>&#160;</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>&#160;</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>&#160;</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>&#160;</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 &lt; 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>&#160;</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>&#160;</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 &lt; 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>&#160;</p>

<p>&#160;</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
&lt;date&gt;</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>&#160;</p>

<p>&#160;</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 &amp; 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 &amp; 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 &amp; 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 &amp; Return</td>
<td>Task</td>
</tr>

<tr>
<td><a href="#partial_date">Date, partially-specified</a></td>
<td>Should</td>
<td>Configure &amp; 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 &amp; 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 &amp; 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 &amp;
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 &amp; 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 &amp; 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 &amp; Return</td>
<td>Task</td>
</tr>

<tr>
<td><a href="#natural_numbers">Natural numbers</a></td>
<td>Must</td>
<td>Configure &amp; Return</td>
<td>Task</td>
</tr>

<tr>
<td><a href="#simple_digit">Simple digit string</a></td>
<td>Must</td>
<td>Configure &amp; Return</td>
<td>Task</td>
</tr>

<tr>
<td><a href="#full_date">Fully-specified date</a></td>
<td>Must</td>
<td>Configure &amp; 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 &amp; Return</td>
<td>Task</td>
</tr>

<tr>
<td><a href="#simple_alpha">Simple alpha string</a></td>
<td>Should</td>
<td>Configure &amp; Return</td>
<td>Task</td>
</tr>

<tr>
<td><a href="#simple_alphanumeric">Simple alphanumeric
string</a></td>
<td>Should</td>
<td>Configure &amp; Return</td>
<td>Task</td>
</tr>

<tr>
<td><a href="#error_template">Simple error-recovery
dialog</a></td>
<td>Should</td>
<td>Configure &amp; 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 &amp; 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 &amp; 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>