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.
3453 lines
121 KiB
3453 lines
121 KiB
<?xml version="1.0" encoding="utf-8"?>
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
|
<html xmlns="http://www.w3.org/1999/xhtml">
|
|
<head><meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
|
<meta name="generator" content="HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
|
|
|
|
<meta http-equiv="Content-Style-Type" content="text/css" />
|
|
|
|
<title>Semantic Interpretation for Speech Recognition (SISR)
|
|
Version 1.0</title>
|
|
<style type="text/css">
|
|
/*<![CDATA[*/
|
|
pre {
|
|
background-color: #d5dee3;
|
|
border-top-width: 4px;
|
|
border-top-style: double;
|
|
border-top-color: #d3d3d3;
|
|
border-bottom-width: 4px;
|
|
border-bottom-style: double;
|
|
border-bottom-color: #d3d3d3;
|
|
padding: 4px;
|
|
margin: 0em;
|
|
}
|
|
.tocline { list-style: none; }
|
|
|
|
ins { color: #00B000; }
|
|
del { color: #B00000; }
|
|
|
|
/*]]>*/
|
|
</style>
|
|
<link rel="stylesheet" type="text/css"
|
|
href="http://www.w3.org/StyleSheets/TR/W3C-REC.css" />
|
|
|
|
</head>
|
|
|
|
<body xml:lang="en" lang="en">
|
|
<div class="head">
|
|
<a href="http://www.w3.org/"><img alt="W3C" src="http://www.w3.org/Icons/w3c_home" height="48" width="72" /></a>
|
|
|
|
<h1 class="notoc" id="top">Semantic Interpretation for Speech
|
|
Recognition (SISR) Version 1.0</h1>
|
|
|
|
<h2 class="notoc" id="wd">W3C Recommendation 5 April 2007</h2>
|
|
|
|
<dl>
|
|
|
|
<dt>This version:</dt>
|
|
|
|
<dd><a href="http://www.w3.org/TR/2007/REC-semantic-interpretation-20070405/">
|
|
http://www.w3.org/TR/2007/REC-semantic-interpretation-20070405/</a></dd>
|
|
|
|
<dt>Latest version:</dt>
|
|
|
|
<dd><a href="http://www.w3.org/TR/semantic-interpretation/">http://www.w3.org/TR/semantic-interpretation/</a></dd>
|
|
|
|
<dt>Previous version:</dt>
|
|
|
|
<dd><a href="http://www.w3.org/TR/2007/PR-semantic-interpretation-20070205/">
|
|
http://www.w3.org/TR/2007/PR-semantic-interpretation-20070205/</a></dd>
|
|
|
|
<dt>Editors:</dt>
|
|
|
|
<dd>Luc Van Tichelen, Nuance Communications
|
|
(<i>Editor-in-Chief</i>)</dd>
|
|
|
|
<dd>Dave Burke, Voxpilot</dd>
|
|
</dl>
|
|
|
|
<p>Please refer to the <a
|
|
href="http://www.w3.org/2007/03/sisr-errata.html"><strong>errata</strong></a>
|
|
|
|
for this document, which may include some normative
|
|
corrections.</p>
|
|
|
|
|
|
<p>See also <a href="http://www.w3.org/2003/03/Translations/byTechnology?technology=semantic-interpretation">
|
|
<strong>translations</strong></a>.</p>
|
|
|
|
<p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a>
|
|
|
|
©2003-2007 <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup>
|
|
|
|
(<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>,
|
|
<a href="http://www.ercim.org/"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>,
|
|
<a href="http://www.keio.ac.jp/">Keio</a>), All Rights
|
|
Reserved. W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">
|
|
|
|
liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a>
|
|
|
|
and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document
|
|
use</a> rules apply.</p>
|
|
|
|
<hr title="Separator for header" />
|
|
</div>
|
|
|
|
<h2 class="notoc"><a id="abstract" name="abstract">Abstract</a></h2>
|
|
|
|
<p>This document defines the process of Semantic Interpretation
|
|
for Speech Recognition and the syntax and semantics of semantic
|
|
interpretation tags that can be added to speech recognition
|
|
grammars to compute information to return to an application on
|
|
the basis of rules and tokens that were matched by the speech
|
|
recognizer. In particular, it defines the syntax and semantics of
|
|
the contents of Tags in the Speech Recognition Grammar
|
|
Specification [<a href="#refSRGS">SRGS</a>].</p>
|
|
|
|
<p>The results of semantic interpretation describe the meaning of
|
|
a natural language utterance. The current specification
|
|
represents this information as an ECMAScript object, and defines
|
|
a mechanism to serialize the result into [<a href="#refXML">XML</a>].
|
|
The W3C Multimodal
|
|
Interaction Activity [<a href="#refMMI">MMI</a>] is defining an
|
|
XML data format [<a href="#refEMMA">EMMA</a>] for containing and
|
|
annotating the information in user utterances. It is expected
|
|
that the EMMA language will be able to integrate results
|
|
generated by Semantic Interpretation for Speech Recognition.</p>
|
|
|
|
<p>Semantic Interpretation may be useful in combination with
|
|
other specifications, such as Stochastic Language Models
|
|
[<a href="#refNgrams">N-GRAM</a>], but their use with N-grams has
|
|
not yet been studied.</p>
|
|
|
|
<h2><a name="status" id="status">Status of This Document</a></h2>
|
|
|
|
<p><em>This section describes the status of this document at the
|
|
time of its publication. Other documents may supersede this
|
|
document. A list of current W3C publications and the latest
|
|
revision of this technical report can be found in the <a
|
|
href="http://www.w3.org/TR/">W3C technical reports index</a> at
|
|
http://www.w3.org/TR/.</em></p>
|
|
|
|
<p>This is the <a href=
|
|
"http://www.w3.org/2005/10/Process-20051014/tr.html#RecsW3C">Recommendation</a>
|
|
of
|
|
Semantic Interpretation for Speech Recognition (SISR) Version 1.0 specification.
|
|
|
|
It has been produced by the
|
|
<a href="http://www.w3.org/Voice/">Voice Browser Working Group</a>,
|
|
which is part of the
|
|
<a href="http://www.w3.org/Voice/Activity.html">Voice Browser Activity</a>.
|
|
</p>
|
|
|
|
<p>Comments are welcome on <a
|
|
href="mailto:www-voice@w3.org">www-voice@w3.org</a> (<a
|
|
href="http://lists.w3.org/Archives/Public/www-voice/">archive</a>).
|
|
See <a href="http://www.w3.org/Mail/">W3C mailing list and archive
|
|
usage guidelines</a>.</p>
|
|
|
|
|
|
<p>The design of SISR 1.0 has been widely reviewed (see the <a
|
|
href="http://www.w3.org/TR/2007/PR-semantic-interpretation-20070205/sisr10-disp.html">
|
|
disposition of comments</a>) and satisfies the Working Group's
|
|
technical requirements. A list of implementations is included in
|
|
the <a href="http://www.w3.org/Voice/2007/sisr-ir/">
|
|
|
|
SISR 1.0 Implementation Report</a>, along with the associated test
|
|
suite.
|
|
|
|
The Working Group made the following editorial changes to the
|
|
<a href="http://www.w3.org/TR/2007/PR-semantic-interpretation-20070205/">
|
|
5 February 2007 Proposed Recommendation</a> in response to
|
|
comments: split references into normative and informative categories,
|
|
updated the [<a href="#refXMLNames">XML-NAMES</a>] reference, and
|
|
added the [<a href="#refXML">XML</a>] and [<a href="#refXMLSchema">XML-SCHEMA</a>]
|
|
references.
|
|
</p>
|
|
|
|
<p>This document has been reviewed by W3C Members, by software
|
|
developers, and by other W3C groups and interested parties, and is
|
|
endorsed by the Director as a W3C Recommendation. It is a stable
|
|
document and may be used as reference material or cited from
|
|
another document. W3C's role in making the Recommendation is to
|
|
draw attention to the specification and to promote its widespread
|
|
deployment. This enhances the functionality and interoperability
|
|
of the Web.</p>
|
|
|
|
<p>This document was produced by a group operating under the
|
|
<a href="http://www.w3.org/Consortium/Patent-Policy-20040205/">
|
|
5 February 2004 W3C Patent Policy</a>.
|
|
|
|
W3C maintains a
|
|
<a rel="disclosure" href="http://www.w3.org/2004/01/pp-impl/34665/status">
|
|
public list of any patent disclosures</a> made in connection with the
|
|
deliverables of the group; that page also includes instructions
|
|
for disclosing a patent.
|
|
|
|
An individual who has actual knowledge of a patent which the
|
|
individual believes contains Essential Claim(s) must disclose the
|
|
information in accordance with
|
|
<a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">
|
|
|
|
section 6 of the W3C Patent Policy</a>.</p>
|
|
|
|
<h2 id="Table"><a name="contents" id="contents">Table of
|
|
Contents</a></h2>
|
|
|
|
<ul>
|
|
<li class="tocline">1 <a href="#SI1">Introduction</a>
|
|
|
|
<ul>
|
|
|
|
<li class="tocline">1.1 <a href="#SI1.1">Semantic
|
|
Interpretation</a></li>
|
|
|
|
<li class="tocline">1.2 <a href="#SI1.2">Basic
|
|
Principles</a></li>
|
|
</ul>
|
|
</li>
|
|
|
|
<li class="tocline">2 <a href="#SI2">Notational
|
|
Conventions</a></li>
|
|
|
|
<li class="tocline">3 <a href="#SI3">Expressions in Semantic
|
|
Interpretation Tags</a>
|
|
|
|
<ul>
|
|
<li class="tocline">3.1 <a href="#SI3.1">Rule Variables and
|
|
Semantic Values</a>
|
|
|
|
<ul>
|
|
<li class="tocline">3.1.1 <a href="#SI3.1.1">Implementation Notes</a></li>
|
|
|
|
</ul>
|
|
|
|
</li>
|
|
|
|
<li class="tocline">3.2 <a href="#SI3.2">Semantic
|
|
Interpretation Tags</a>
|
|
|
|
<ul>
|
|
<li class="tocline">3.2.1 <a href="#SI3.2.1">Adding
|
|
Semantic Interpretation Tags to Grammars</a></li>
|
|
|
|
<li class="tocline">3.2.2 <a href="#SI3.2.2">Semantic
|
|
Interpretation Scripts</a></li>
|
|
|
|
<li class="tocline">3.2.3 <a href="#SI3.2.3">Semantic
|
|
Interpretation String Literals</a></li>
|
|
|
|
<li class="tocline">3.2.4 <a href="#SI3.2.4">Authoring
|
|
Notes</a></li>
|
|
</ul>
|
|
|
|
</li>
|
|
|
|
<li class="tocline">3.3 <a href="#SI3.3">Syntax for Rule
|
|
Variables</a>
|
|
|
|
<ul>
|
|
<li class="tocline">3.3.1 <a href="#SI3.3.1">Accessing
|
|
the Rule Variable</a></li>
|
|
|
|
<li class="tocline">3.3.2 <a href="#SI3.3.2">Accessing
|
|
the Rule Variable of a Referenced Grammar Rule</a></li>
|
|
|
|
<li class="tocline">3.3.3 <a href="#SI3.3.3">Accessing
|
|
Variables Associated with a Grammar Rule or Referenced
|
|
Grammar Rule</a></li>
|
|
|
|
</ul>
|
|
</li>
|
|
</ul>
|
|
</li>
|
|
|
|
<li class="tocline">4 <a href="#SI4">Semantic Interpretation
|
|
Grammars</a>
|
|
|
|
<ul>
|
|
|
|
<li class="tocline">4.1 <a href="#SI4.1">Semantic
|
|
Interpretation Grammars</a></li>
|
|
|
|
<li class="tocline">4.2 <a href="#SI4.2">Global Variable
|
|
Declarations and Initialization</a></li>
|
|
|
|
</ul>
|
|
</li>
|
|
|
|
<li class="tocline">5 <a href="#SI5">Default
|
|
Assignment</a></li>
|
|
|
|
<li class="tocline">6 <a href="#SI6">Visibility Rules and Order
|
|
of Tag Evaluation for SRGS Grammars</a>
|
|
|
|
<ul>
|
|
|
|
<li class="tocline">6.1 <a href="#SI6.1">Logical Parse
|
|
Structure</a></li>
|
|
|
|
<li class="tocline">6.2 <a href="#SI6.2">Flat Parse
|
|
List</a></li>
|
|
|
|
<li class="tocline">6.3 <a href="#SI6.3">Scoping and
|
|
Visibility Rules for Script Tag Syntax Grammars</a>
|
|
|
|
<ul>
|
|
|
|
<li class="tocline">6.3.1 <a href="#SI6.3.1">The Global
|
|
Scope</a></li>
|
|
|
|
<li class="tocline">6.3.2 <a href="#SI6.3.2">Scope
|
|
Chains and Access to Variables</a></li>
|
|
|
|
<li class="tocline">6.3.3 <a href="#SI6.3.3">Visibility</a></li>
|
|
|
|
<li class="tocline">6.3.4 <a href="#SI6.3.4">Global
|
|
Variables</a></li>
|
|
|
|
</ul>
|
|
|
|
</li>
|
|
|
|
<li class="tocline">6.4 <a href="#SI6.4">Order of Tag
|
|
Execution for Script Tag Syntax Grammars</a></li>
|
|
|
|
<li class="tocline">6.5 <a href="#SI6.5">Examples</a></li>
|
|
|
|
</ul>
|
|
</li>
|
|
|
|
<li class="tocline">7 <a href="#SI7">Using Semantic
|
|
Interpretation to Generate XML Results</a>
|
|
|
|
<ul>
|
|
<li class="tocline">7.1 <a href="#SI7.1">Serialization of
|
|
an ECMAScript Result into an XML Fragment</a></li>
|
|
|
|
<li class="tocline">7.2 <a href="#SI7.2">Use of _attributes
|
|
and _value</a></li>
|
|
|
|
<li class="tocline">7.3 <a href="#SI7.3">Namespaces</a></li>
|
|
|
|
</ul>
|
|
</li>
|
|
|
|
<li class="tocline">8 <a href="#SI8">Example Grammars with
|
|
Semantic Interpretation Tags</a>
|
|
|
|
<ul>
|
|
<li class="tocline">8.1 <a href="#SI8.1">Example 1</a></li>
|
|
|
|
<li class="tocline">8.2 <a href="#SI8.2">Example 2</a></li>
|
|
|
|
</ul>
|
|
</li>
|
|
|
|
</ul>
|
|
|
|
<h3><a name="appendices" id="appendices">Appendices</a></h3>
|
|
|
|
<ul>
|
|
|
|
<li class="tocline">A <a href="#SIA">Conformance</a>
|
|
|
|
<ul>
|
|
|
|
<li class="tocline">A.1 <a href="#SIA.1">Conforming
|
|
Semantic Interpretation Tags</a></li>
|
|
|
|
<li class="tocline">A.2 <a href="#SIA.2">Conforming Grammar
|
|
Documents and Fragments with Semantic Interpretation
|
|
Tags</a></li>
|
|
|
|
<li class="tocline">A.3 <a href="#SIA.3">Conforming
|
|
Semantic Interpretation Processors</a></li>
|
|
|
|
<li class="tocline">A.4 <a href="#SIA.4">Conforming
|
|
Semantic Interpretation Grammar Processors</a></li>
|
|
|
|
<li class="tocline">A.5 <a href="#SIA.5">Conformance
|
|
Statements</a>
|
|
|
|
<ul>
|
|
|
|
<li class="tocline">A.5.1 <a href="#SIA.5.1">Conformance Statement for Conforming
|
|
Documents</a></li>
|
|
|
|
<li class="tocline">A.5.2 <a href="#SIA.5.2">Conformance Statement for Conforming
|
|
Processor</a></li>
|
|
|
|
</ul>
|
|
</li>
|
|
|
|
</ul>
|
|
</li>
|
|
|
|
<li class="tocline">B <a href="#SIB">Glossary</a></li>
|
|
|
|
<li class="tocline">C <a href="#SIC">Normative
|
|
References</a></li>
|
|
|
|
<li class="tocline">D <a href="#SID">Informative
|
|
References</a></li>
|
|
|
|
<li class="tocline">E <a href="#SIE">Acknowledgments</a></li>
|
|
|
|
</ul>
|
|
<hr />
|
|
|
|
<h1 id="L540"><a name="SI1" id="SI1">1 Introduction</a></h1>
|
|
|
|
<p><strong>This section is informative.</strong></p>
|
|
|
|
<h2 id="L545"><a name="SI1.1" id="SI1.1">1.1 Semantic
|
|
Interpretation</a></h2>
|
|
|
|
<p>Grammar Processors, and in particular speech recognizers, use
|
|
a grammar that defines the words and sequences of words to define
|
|
the input language that they can accept. The major task of a
|
|
grammar processor consists of finding the sequence of words
|
|
described by the grammar that (best) matches a given utterance,
|
|
or to report that no such sequence exists.</p>
|
|
|
|
<p>In an application, knowing the sequence of words that were
|
|
uttered is sometimes interesting but often not the most practical
|
|
way of handling the information that is present in the user
|
|
utterance. What is needed is a computer processable
|
|
representation of the information, the Semantic Result, more than
|
|
a natural language transcript. The process of producing a
|
|
Semantic Result representing the meaning of a natural language
|
|
utterance is called Semantic Interpretation (SI).</p>
|
|
|
|
<p>The Semantic Interpretation process described in this
|
|
specification uses Semantic Interpretation Tags (SI Tags) (see
|
|
section <a href="#SI3.2">3.2</a>) to provide a means to attach
|
|
instructions for the computation of such semantic results to a
|
|
speech recognition grammar. When used with a [<a href="#refVoiceXML">VOICEXML20</a>] Processor, it is expected that a
|
|
Semantic Interpretation Grammar Processor will convert the result
|
|
generated by an [<a href="#refSRGS">SRGS</a>] speech grammar
|
|
processor into an ECMAScript object that can then be processed as
|
|
specified in section 3.1.6 Mapping Semantic Interpretation
|
|
Results to VoiceXML Forms in [<a href="#refVoiceXML">VOICEXML20</a>].</p>
|
|
|
|
<p>The W3C Multimodal Interaction Activity [<a href="#refMMI">MMI</a>] is defining an XML data format [<a href="#refEMMA">EMMA</a>] for containing and annotating the
|
|
information in user utterances. It is expected that the EMMA
|
|
language will be able to integrate results generated by Semantic
|
|
Interpretation for Speech Recognition.</p>
|
|
|
|
<p>This document defines the syntax and the semantics of Semantic
|
|
Interpretation Tags for use with the Speech Recognition Grammar
|
|
Specification [<a href="#refSRGS">SRGS</a>]. It is possible that
|
|
Semantic Interpretation Tags as defined here can be used also
|
|
with Stochastic Language Models [<a href="#refNgrams">N-GRAM</a>], but the current specification does not
|
|
specifically address such use and does not guarantee that the
|
|
Semantic Interpretation Tags as defined here are meeting the
|
|
needs of such use.</p>
|
|
|
|
<h2 id="L574"><a name="SI1.2" id="SI1.2">1.2 Basic
|
|
Principles</a></h2>
|
|
|
|
<p>The basic principles for the Semantic Interpretation mechanism
|
|
defined in this specification are the following:</p>
|
|
|
|
<ul>
|
|
<li>semantic information is represented as values associated
|
|
with non-terminals</li>
|
|
|
|
<li>statements in Semantic Interpretation Tags are either valid
|
|
ECMAScript code (Compact Profile) or string literals</li>
|
|
|
|
<li>expression evaluation order is connected to the grammar
|
|
rule definitions and the sequence of words in the recognized
|
|
utterance</li>
|
|
</ul>
|
|
|
|
<p>This specification uses the ECMAScript Compact Profile
|
|
[<a href="#refECMA327">ECMA-327</a>], which is a strict subset of
|
|
[<a href="#refECMA262">ECMA-262</a>]. [<a href="#refECMA327">ECMA-327</a>] has been designed to meet the needs
|
|
of resource-constrained environments. Special attention has been
|
|
paid to constraining ECMAScript features that require
|
|
proportionately large amounts of system memory, and continuous or
|
|
proportionately large amounts of processing power. In particular,
|
|
it is designed to facilitate prior compilation for execution in a
|
|
lightweight environment. This makes it attractive for use in
|
|
association with speech grammar rules for extracting semantic
|
|
results from speech recognition.</p>
|
|
|
|
<h1 id="L618"><a name="SI2" id="SI2">2 Notational
|
|
Conventions</a></h1>
|
|
|
|
<p>In this document, the key words "must", "must not",
|
|
"required", "shall", "shall not", "should", "should not",
|
|
"recommended", "may", and "optional" are to be interpreted as
|
|
described in [<a href="#refRFC2119">RFC2119</a>]. Requirement
|
|
levels for conforming Semantic Interpretation for Speech
|
|
Recognition implementations are defined in <a href="#SIA">Appendix A</a>.</p>
|
|
|
|
<p>The sections in the main body of this document are normative
|
|
unless otherwise specified. The appendices and examples in this
|
|
document are informative unless otherwise indicated
|
|
explicitly.</p>
|
|
|
|
<p>This specification normatively references [<a href="#refECMA327">ECMA-327</a>], which in turn references [<a href="#refECMA262">ECMA-262</a>]. The notation ES <i>n</i> is used in
|
|
this document as shorthand for section number <i>n</i> in
|
|
[<a href="#refECMA262">ECMA-262</a>].</p>
|
|
|
|
<h1 id="L836"><a name="SI3" id="SI3">3 Expressions in Semantic
|
|
Interpretation Tags</a></h1>
|
|
|
|
<h2 id="L839"><a name="SI3.1" id="SI3.1">3.1 Rule Variables and
|
|
Semantic Values</a></h2>
|
|
|
|
<p>SI Tags compute semantic values. During the semantic
|
|
interpretation process, these values can be assigned to variables
|
|
that are associated with the rules in the grammar. These
|
|
variables are known as Rule Variables.</p>
|
|
|
|
<p>Every grammar rule has a single Rule Variable that holds a
|
|
semantic value. The Rule Variable is typically assigned its value
|
|
by the SI Tags within its grammar rule. SI Tags also have access
|
|
to the Rule Variables of any other rules referenced by the
|
|
current grammar rule and already processed up to that point in
|
|
the utterance (according to the visibility constraints defined in
|
|
section <a href="#SI6">6</a>). The Rule Variables of other rules
|
|
are referenced by the name of their grammar rule, as described in
|
|
section <a href="#SI3.3.2">3.3.2</a>.</p>
|
|
|
|
<p>Rule Variables can hold semantic values of any type defined in
|
|
[<a href="#refECMA327">ECMA-327</a>]. They are not explicitly
|
|
typed. Rule Variables that have not been assigned a value are not
|
|
defined. SI authors will typically use scalar types, e.g. string
|
|
or numeric values, in lower level rules and more structured
|
|
objects in higher level rules (particularly root rules).</p>
|
|
|
|
<p>In addition to semantic values, certain other values
|
|
corresponding to Rule Variables are available during SI
|
|
processing.</p>
|
|
|
|
<p>For every Rule Variable there is an associated variable named
|
|
<code>text</code>, of type String, which holds the substring (the
|
|
series of tokens) in the utterance that is governed by the
|
|
corresponding grammar rule. Text variables are not part of the
|
|
Rule Variable (see section <a href="#SI3.3.3">3.3.3</a>) and the
|
|
value of the text variables cannot be modified.</p>
|
|
|
|
<p>Likewise, for every Rule Variable, there is an associated
|
|
variable called <code>score</code>, of type Number, which holds a
|
|
value that is related to the confidence or probability of the
|
|
corresponding grammar rule or some similar measure. Higher score
|
|
values indicate higher confidence or probability over the
|
|
corresponding grammar rule. Processors that don't compute or
|
|
don't have access to such values must return undefined as the
|
|
score value. Score variables are not part of the Rule Variable
|
|
and the value of the score variables cannot be modified.</p>
|
|
|
|
<p>The semantic result for an utterance is the value of the Rule
|
|
Variable of the root rule when all semantic interpretation
|
|
evaluations have been completed. For certain result formats (e.g.
|
|
[<a href="#refEMMA">EMMA</a>]), this value is serialized into an
|
|
[<a href="#refXML">XML</a>] document according to the description in section <a href="#SI7">7</a>. It is outside the scope of this specification to
|
|
define how the semantic result is communicated to the
|
|
application.</p>
|
|
|
|
<h3 id="L2123"><a name="SI3.1.1" id="SI3.1.1">3.1.1
|
|
Implementation Notes</a></h3>
|
|
|
|
<p><strong>This section is informative.</strong></p>
|
|
|
|
<p>In the context of the W3C Voice Browser architecture, the
|
|
semantic result will be directly cast into ECMAScript variables
|
|
in the VoiceXML interpreter (see section 3.1.6 in [<a href="#refVoiceXML">VOICEXML20</a>]). In the W3C Multimodal
|
|
Interaction Framework <a href="#refMMI-Arch">[MMI-FRAMEWORK]</a>,
|
|
the semantic result is expected to be transformed into EMMA
|
|
following the mechanism described in section <a href="#SI7">7</a>. In other contexts, the mechanism described in
|
|
section <a href="#SI7">7</a> can be used to transform the
|
|
semantic result into other XML formats.</p>
|
|
|
|
<p>Score values are highly dependent on the processor's
|
|
implementation. In most implementations using speech recognition,
|
|
scores are likely to be dependent on factors such as audio
|
|
channel quality, grammar contents, grammar weights, language,
|
|
individual speaker characteristics, and others. Scores for a
|
|
particular word or phrase within a grammar are typically
|
|
comparable over instances of the same word or phrase over time.
|
|
Scores for different words in a single grammar are also typically
|
|
comparable to one another. Scores across grammars, or scores for
|
|
words and word sequences, or scores between different processors,
|
|
are very often not comparable. It is anticipated that scores will
|
|
be useful only for annotating the results, not for influencing
|
|
the results during SI processing. Note that an SI processor
|
|
doesn't require a speech recognizer, and thus that the score does
|
|
not even have to be related to speech recognition.</p>
|
|
|
|
<h2 id="L863"><a name="SI3.2" id="SI3.2">3.2 Semantic
|
|
Interpretation Tags</a></h2>
|
|
|
|
<p>Semantic Interpretation Tags are added in the string content
|
|
of the <code>tag</code> elements in the grammar rule expansion,
|
|
as described in section 2.6 of [<a href="#refSRGS">SRGS</a>].
|
|
This specification further uses the term Semantic Interpretation
|
|
Tag (or SI Tag) to refer to such tag.</p>
|
|
|
|
<p>This specification defines two different Semantic
|
|
Interpretation tag syntaxes. The two different possible values of
|
|
the <code>tag-format</code> declaration in the grammar define
|
|
which of the two syntaxes is being used. The different syntaxes
|
|
only change the processing of tags during Semantic
|
|
Interpretation, in all other respects the grammar behaves
|
|
identically.</p>
|
|
|
|
<p>The "Script" tag syntax, enabled by setting the
|
|
<code>tag-format</code> to <code>semantics/1.0</code>, defines
|
|
the contents of tags to be ECMAScript. Each tag is a valid
|
|
[<a href="#refECMA327">ECMA-327</a>] program. Section <a href="#SI3.2.2">3.2.2</a> describes the processing of this tag syntax
|
|
in more detail.</p>
|
|
|
|
<p>The "String Literal" tag syntax, enabled by setting the
|
|
<code>tag-format</code> to <code>semantics/1.0-literals</code>,
|
|
defines the contents of tags to be strings. This syntax does not
|
|
have the expressive power of a full scripting language, but does
|
|
provide a way to produce semantic results consisting of simple
|
|
strings. Section <a href="#SI3.2.3">3.2.3</a> describes this tag
|
|
syntax in more detail.</p>
|
|
|
|
<p>Within one grammar, it is not possible to mix the two tag
|
|
syntaxes. All tags in one grammar must have the same
|
|
<code>tag-format</code>. However, it is possible for externally
|
|
referenced grammars to have a different <code>tag-format</code>
|
|
|
|
to the parent grammar from which they are referenced from.</p>
|
|
|
|
<h3 id="L1232"><a name="SI3.2.1" id="SI3.2.1">3.2.1 Adding
|
|
Semantic Interpretation Tags to Grammars</a></h3>
|
|
|
|
<p>Below are two example formats of SI Tags in the Speech
|
|
Recognition Grammar Specification [<a href="#refSRGS">SRGS</a>]
|
|
(<i>tag-content</i> represents the content of the tag which can
|
|
be either ECMAScript code or a String Literal).</p>
|
|
|
|
<p>In the XML grammar format, SI Tags are specified as the
|
|
content of the <code><tag></code> element:</p>
|
|
<pre class="sample">
|
|
<tag> <i>tag-content</i> </tag>
|
|
</pre>
|
|
|
|
<p>In the ABNF grammar format, SI Tags are enclosed in curly
|
|
braces or in the three-character sequences <code>'{!{'</code> and
|
|
<code>'}!}'</code>:</p>
|
|
|
|
<pre class="sample">
|
|
{ <i>tag-content</i> }
|
|
{!{ <i>tag-content</i> }!}</pre>
|
|
|
|
<h3><a name="SI3.2.2" id="SI3.2.2">3.2.2 Semantic Interpretation
|
|
Scripts</a></h3>
|
|
|
|
<p>A Semantic Interpretation Script (SI Script) holds a string
|
|
that is treated as the source text of a valid [<a href="#refECMA327">ECMA-327</a>] Program ("Program" is defined by ES
|
|
14).</p>
|
|
|
|
<p>The environment in which SI Tags are embedded may introduce
|
|
escaped characters, character references, or other markup that
|
|
has to be resolved by the environment. The result after
|
|
resolution is treated as ECMAScript code.</p>
|
|
|
|
<p>It is illegal to make an assignment to a variable that has not
|
|
been previously declared (either implicitly as is the case for
|
|
Rule Variables or explicitly by using a <code>var</code>
|
|
|
|
statement). Attempting to assign to an undeclared variable will
|
|
result in a runtime error.</p>
|
|
|
|
<h3 id="L923"><a name="SI3.2.3" id="SI3.2.3">3.2.3 Semantic
|
|
Interpretation String Literals</a></h3>
|
|
|
|
<p>A tag using the String Literal tag syntax has content that is
|
|
a sequence of zero or more characters. If the character sequence
|
|
is not empty, it has to follow either the
|
|
<code>DoubleStringCharacters</code> or the
|
|
<code>SingleStringCharacters</code> production of ES 7.8.4</p>
|
|
|
|
<p>During processing, a tag with a String Literal has the same
|
|
effect as a script that assigns the content of the tag, as a
|
|
string literal, to the Rule Variable of the rule the tag is
|
|
in.</p>
|
|
|
|
<h3 id="L9231"><a name="SI3.2.4" id="SI3.2.4">3.2.4 Authoring
|
|
Notes</a></h3>
|
|
|
|
<p><strong>This section is informative.</strong></p>
|
|
|
|
<p>If multiple tags are present in the rule expansion, the Rule
|
|
Variable is set to the value of the last tag in the expansion.
|
|
Prior tags are overwritten by the final tag.</p>
|
|
|
|
<p>A grammar using the Script tag syntax can reference rules of a
|
|
grammar using the String Literal tag syntax. The value of the
|
|
string literal can be obtained by the parent rule using the Rule
|
|
Variable of the referenced rule. The recognized text of the
|
|
referenced rule is also available in the
|
|
<code>meta.latest().text</code> and
|
|
<code>meta.rulename.text</code> variables (where
|
|
<code>rulename</code> is the name of the rule).</p>
|
|
|
|
<p>A grammar using the String Literal tag syntax can reference
|
|
rules in other grammars (which can be using either the Script tag
|
|
syntax or the String Literal tag syntax). One consequence of this
|
|
is that a grammar using the String Literal tag syntax can return
|
|
a non-string result (e.g. an ECMAScript Object, Number, Boolean,
|
|
etc) if it references a grammar that uses the Script tag syntax
|
|
which returns a non-string result. See section <a href="#SI5">5</a> for the way semantic results from a referenced
|
|
grammar can be used in a grammar with String Literal tag
|
|
syntax.</p>
|
|
|
|
<p>Authors should take care to set the <code>tag-format</code>
|
|
correctly. Using the String Literal tag syntax when the
|
|
<code>tag-format</code> is set to <code>semantics/1.0</code> will
|
|
generally result in a runtime error. However, the converse (using
|
|
the Script tag syntax when the <code>tag-format</code> is set to
|
|
<code>semantics/1.0-literals</code>) will not produce a runtime
|
|
error but rather result in erroneously populating Rule Variables
|
|
with ECMAScript code.</p>
|
|
|
|
<h5 class="qualif">Examples:</h5>
|
|
|
|
<p>Examples of equivalent grammars, one using the Script tag
|
|
syntax and the other using the String Literal tag syntax, are
|
|
given below for both the XML Form and ABNF Form.</p>
|
|
|
|
<h5>XML Form</h5>
|
|
<pre class="xml">
|
|
<grammar version="1.0" xmlns="http://www.w3.org/2001/06/grammar"
|
|
xml:lang="en-US" tag-format="semantics/1.0-literals" root="answer">
|
|
<rule id="answer" scope="public">
|
|
|
|
<one-of>
|
|
<item><ruleref uri="#yes"/></item>
|
|
<item><ruleref uri="#no"/></item>
|
|
</one-of>
|
|
</rule>
|
|
|
|
<rule id="yes">
|
|
<one-of>
|
|
<item>yes</item>
|
|
<item>yeah<tag>yes</tag></item>
|
|
|
|
<item><token>you bet</token><tag>yes</tag></item>
|
|
<item xml:lang="fr-CA">oui<tag>yes</tag></item>
|
|
|
|
</one-of>
|
|
</rule>
|
|
<rule id="no">
|
|
<one-of>
|
|
<item>no</item>
|
|
|
|
<item>nope</item>
|
|
<item>no way</item>
|
|
</one-of>
|
|
<tag>no</tag>
|
|
|
|
</rule>
|
|
</grammar>
|
|
</pre>
|
|
|
|
<p>The grammar above with the String Literal tag syntax is
|
|
equivalent to the grammar below with the Script tag syntax:</p>
|
|
<pre class="xml">
|
|
<grammar version="1.0" xmlns="http://www.w3.org/2001/06/grammar"
|
|
xml:lang="en-US" tag-format="semantics/1.0" root="answer">
|
|
<rule id="answer" scope="public">
|
|
|
|
<one-of>
|
|
<item><ruleref uri="#yes"/></item>
|
|
<item><ruleref uri="#no"/></item>
|
|
</one-of>
|
|
</rule>
|
|
|
|
<rule id="yes">
|
|
<one-of>
|
|
<item>yes</item>
|
|
<item>yeah<tag>out="yes";</tag></item>
|
|
|
|
<item><token>you bet</token><tag>out="yes";</tag></item>
|
|
<item xml:lang="fr-CA">oui<tag>out="yes";</tag></item>
|
|
|
|
</one-of>
|
|
</rule>
|
|
<rule id="no">
|
|
<one-of>
|
|
<item>no</item>
|
|
|
|
<item>nope</item>
|
|
<item>no way</item>
|
|
</one-of>
|
|
<tag>out="no";</tag>
|
|
|
|
</rule>
|
|
</grammar>
|
|
</pre>
|
|
|
|
<h5>ABNF Form</h5>
|
|
<pre class="abnf">
|
|
#ABNF 1.0;
|
|
language en-US;
|
|
tag-format <semantics/1.0-literals>;
|
|
root $answer;
|
|
public $answer = $yes | $no;
|
|
$yes = yes | yeah {yes} | "you bet" {!{yes}!} | "oui"!fr-CA {yes};
|
|
$no = (no | nope | no way) {no};
|
|
</pre>
|
|
|
|
<p>The grammar above with the String Literal tag syntax is
|
|
equivalent to the grammar below with the Script tag syntax:</p>
|
|
<pre class="abnf">
|
|
#ABNF 1.0;
|
|
language en-US;
|
|
tag-format <semantics/1.0>;
|
|
root $answer;
|
|
public $answer = $yes | $no;
|
|
$yes = yes | yeah {out="yes";} | "you bet" {!{out="yes";}!} |
|
|
"oui"!fr-CA {out="yes";};
|
|
$no = (no | nope | no way) {out="no";};
|
|
</pre>
|
|
|
|
<h2 id="L1108"><a name="SI3.3" id="SI3.3">3.3 Syntax for Rule
|
|
Variables</a></h2>
|
|
|
|
<p>A <a href="#SI3.2.2">SI Script</a> can access Rule Variables
|
|
using the syntax defined in this section. This syntax applies
|
|
only to documents for which the SI Tags hold SI Scripts (and not
|
|
to documents where SI Tags contain the <a href="#SI3.2.3">String
|
|
Literals</a> tag syntax).</p>
|
|
|
|
<h3 id="L1111"><a name="SI3.3.1" id="SI3.3.1">3.3.1 Accessing the
|
|
Rule Variable</a></h3>
|
|
|
|
<p>Every grammar rule has a single Rule Variable that holds a
|
|
[<a href="#refECMA327">ECMA-327</a>] value. This Rule Variable
|
|
can both be evaluated and assigned to.</p>
|
|
|
|
<p>The Rule Variable is identified by <code>out</code>.</p>
|
|
|
|
<p>Properties of the Rule Variable can be individually accessed
|
|
by <code>out.identifier</code>, where <code>identifier</code> is
|
|
the name of the property.</p>
|
|
<pre class="sample">
|
|
out (identifies the Rule Variable)
|
|
out.pizza (identifies the pizza property of the Rule Variable)
|
|
</pre>
|
|
|
|
<h4 id="L3311"><a name="SI3.3.1.1" id="SI3.3.1.1">3.3.1.1
|
|
Authoring Notes</a></h4>
|
|
|
|
<p><strong>This section is informative.</strong></p>
|
|
|
|
<p>The Semantic Interpretation Script typically assigns a value
|
|
to the Rule Variable of its embedding grammar rule. The Rule
|
|
Variable is initialized to an empty Object before the first tag
|
|
in the grammar rule is executed (see section <a href="#SI6.3">6.3</a>). The SI author will usually either add
|
|
properties to this Object or alternatively discard it by
|
|
assigning a primitive value (e.g. String or Number) to the Rule
|
|
Variable. Since the Rule Variable is initialized before the tag
|
|
is executed, a <code>var</code> statement is not required prior
|
|
to assigning to it.</p>
|
|
|
|
<p>As a consequence of normal ECMAScript behavior, the SI author
|
|
is free to override the Rule Variable type as well as value
|
|
within the bounds of legal ECMAScript. Note that [<a href="#refECMA327">ECMA-327</a>] enforces rules that affect Semantic
|
|
Interpretation Scripts. For example, [<a href="#refECMA327">ECMA-327</a>] reserved words cannot be used as a
|
|
property. Thus, <code>out.for</code> is illegal because it uses
|
|
the [<a href="#refECMA327">ECMA-327</a>] reserved word
|
|
<code>for</code>.</p>
|
|
|
|
<h5 class="qualif">Examples:</h5>
|
|
<!-- Removed code element in example below -->
|
|
<pre class="sample">
|
|
// An Object with property name prop
|
|
out.prop = "my property";
|
|
|
|
// A String with value "my value"
|
|
out = "my value";
|
|
|
|
// A String with value "my value"
|
|
out.prop = "my property"; out = "my value";
|
|
|
|
// A String with value "my value"
|
|
out = "my value"; out.prop = "my property";
|
|
|
|
// A String with value "ab"
|
|
out.prop1 = "a"; out.prop2 = "b"; out = out.prop1 + out.prop2;
|
|
|
|
// An Object with property name prop
|
|
out = "my value"; out = new Object(); out.prop = "my property";
|
|
</pre>
|
|
|
|
<h3 id="L1211"><a name="SI3.3.2" id="SI3.3.2">3.3.2 Accessing the
|
|
Rule Variable of a Referenced Grammar Rule</a></h3>
|
|
|
|
<p>SI Scripts can access the Rule Variable associated with
|
|
grammar rules referenced in SI Tags that appear after (to the
|
|
right or below) the rule reference in the grammar expansion, and
|
|
only if the referenced rule was used in the expansion that
|
|
matched the input utterance. See visibility rules in section
|
|
<a href="#SI6">6</a> for a more detailed description of when Rule
|
|
Variables associated to rule references can be referenced in SI
|
|
Tags, using the concept of the logical parse structure and the
|
|
flat parse list.</p>
|
|
|
|
<p>Rule Variables associated to referenced rules can both be
|
|
evaluated and assigned to. Every SI Script has access to a
|
|
<code>rules</code> object that has a property holding the Rule
|
|
Variable value for every visible rule. The Rule Variable
|
|
associated to a rule reference is identified by
|
|
<code>rules.rulename</code>, where <code>rulename</code> is the
|
|
rulename of the rule, as defined in Section 3.1 Basic Rule
|
|
Definition in [<a href="#refSRGS">SRGS</a>]. Individual
|
|
properties of a Rule Variable can be identified by
|
|
<code>rules.rulename.identifier</code>, where
|
|
<code>rulename</code> is the name of the rule and
|
|
<code>identifier</code> is the name of the property.</p>
|
|
|
|
<p>The Rule Variable for the latest rule reference that was used
|
|
in the expansion matching the utterance up to the position of the
|
|
SI Tag can also be referenced through
|
|
<code>rules.latest()</code>.</p>
|
|
|
|
<p>In an expression, both the Rule Variables of the current
|
|
grammar rule and the referenced rules can be evaluated and
|
|
assigned to.</p>
|
|
|
|
<p>Special rules (NULL, VOID, GARBAGE) cannot be evaluated.</p>
|
|
|
|
<h4 id="L3321"><a name="SI3.3.2.1" id="SI3.3.2.1">3.3.2.1
|
|
Authoring Notes</a></h4>
|
|
|
|
<p><strong>This section is informative.</strong></p>
|
|
|
|
<p>The <code>rules.rulename</code> notation (where
|
|
<code>rulename</code> is the name of a referenced rule) can be
|
|
used equivalently for explicit local rule references, for
|
|
explicit references to a named rule of a grammar, and for
|
|
implicit rule references (see SRGS Section 2.2 Rule Reference in
|
|
[<a href="#refSRGS">SRGS</a>] for a definition of explicit and
|
|
implicit rule references). In the case of a legal implicit rule
|
|
reference, the rule name is indicated by the <code>root</code>
|
|
|
|
attribute of the <code><grammar></code> element (XML form)
|
|
or the <code>root</code> keyword (ABNF form) in the referenced
|
|
grammar.</p>
|
|
|
|
<h5 class="qualif">Examples:</h5>
|
|
<pre class="sample">
|
|
// The Rule Variable associated to the referenced rule "rulename"
|
|
rules.rulename
|
|
|
|
// The property "prop" of the Rule Variable associated with the referenced
|
|
// rule "rulename"
|
|
rules.rulename.prop
|
|
|
|
// The Rule Variable associated to the latest matching rule reference before
|
|
// the SI Tag
|
|
rules.latest()
|
|
|
|
// The property "prop" of Rule Variable associated to latest matching rule
|
|
// reference before the SI Tag
|
|
rules.latest().prop
|
|
|
|
</pre>
|
|
|
|
<p>Section <a href="#SI6">6</a> describes the visibility rules
|
|
for accessing Rule Variables. If according to these rules a Rule
|
|
Variable is not visible, one can still evaluate or declare and
|
|
assign to the variable with that name (it is just a property on
|
|
the <code>rules</code> object). The value assigned to a property
|
|
of the <code>rules</code> object that has the name of a Rule
|
|
Variable will be overwritten when that Rule Variable is visible
|
|
according to section <a href="#SI6">6</a>. This behavior can be
|
|
used to "initialize" Rule Variables to handle cases where a
|
|
referenced rule may not actually be matched depending on the
|
|
input to the grammar.</p>
|
|
|
|
<p>In the following grammar, by declaring and assigning
|
|
<code>rules.foodsize</code> a default value, the value for the
|
|
<code>drink</code> rule will always be:</p>
|
|
|
|
<pre class="sample">
|
|
{
|
|
drinksize: "medium",
|
|
type: "coke"
|
|
}
|
|
</pre>
|
|
|
|
<p>regardless of whether the input is 'coke' or 'medium
|
|
coke':</p>
|
|
|
|
<pre class="xml">
|
|
<grammar version="1.0" xmlns="http://www.w3.org/2001/06/grammar"
|
|
xml:lang="en-US" tag-format="semantics/1.0" root="drink">
|
|
<rule id="drink">
|
|
<-- Note: rules object always exists in scope -->
|
|
<tag>rules.foodsize="medium";</tag>
|
|
<item repeat="0-1">
|
|
|
|
<ruleref uri="#foodsize"/>
|
|
</item>
|
|
<ruleref uri="#kindofdrink"/>
|
|
<tag>out.drinksize=rules.foodsize; out.type=rules.kindofdrink;</tag>
|
|
</rule>
|
|
|
|
<rule id="foodsize">
|
|
<one-of>
|
|
<item>small</item>
|
|
<item>medium</item>
|
|
<item>large</item>
|
|
|
|
</one-of>
|
|
</rule>
|
|
<rule id="kindofdrink">
|
|
<one-of>
|
|
<item>coke</item>
|
|
|
|
<item>pepsi</item>
|
|
</one-of>
|
|
</rule>
|
|
</grammar>
|
|
</pre>
|
|
|
|
<h3 id="L1305"><a name="SI3.3.3" id="SI3.3.3">3.3.3 Accessing
|
|
Variables Associated with a Grammar Rule or Referenced Grammar
|
|
Rule</a></h3>
|
|
|
|
<p>A Rule Variable's text variable is identified by
|
|
<code>meta.rulename.text</code>, where <code>rulename</code> is
|
|
the name of the Rule Variable. The text variable of the Rule
|
|
Variable referred to by <code>rules.latest()</code> is identified
|
|
by <code>meta.latest().text</code>. The text variable associated
|
|
to the current grammar rule is identified by
|
|
<code>meta.current().text</code>. The text variable of the
|
|
current grammar rule is read-only.</p>
|
|
|
|
<p>A Rule Variable's score variable is identified by
|
|
<code>meta.rulename.score</code>, where <code>rulename</code> is
|
|
the name of the Rule Variable. The score variable of the Rule
|
|
Variable referred to by <code>rules.latest()</code> is identified
|
|
by <code>meta.latest().score</code>. The score variable
|
|
associated to the current grammar rule is identified by
|
|
<code>meta.current().score</code>. The score variable of the
|
|
current grammar rule is read-only.</p>
|
|
|
|
<h4 id="L3331"><a name="SI3.3.3.1" id="SI3.3.3.1">3.3.3.1
|
|
Authoring Notes</a></h4>
|
|
|
|
<p><strong>This section is informative.</strong></p>
|
|
|
|
<p>Since the <code>text</code> and <code>score</code> variables
|
|
of the current grammar are read-only, they behave as read-only
|
|
properties as defined in [<a href="#refECMA327">ECMA-327</a>]. As
|
|
a consequence, attempts to assign to the <code>text</code> or
|
|
<code>score</code> variable associated to the Rule Variable of
|
|
the current grammar rule will be ignored. Note, however, that the
|
|
<code>text</code> and <code>score</code> properties of a
|
|
referenced rule (i.e. those properties of
|
|
<code>meta.rulename()</code> where <code>rulename</code> is the
|
|
referenced rule or <code>meta.latest()</code>), are not
|
|
read-only.</p>
|
|
|
|
<h5 class="qualif">Examples:</h5>
|
|
<pre class="sample">
|
|
// The text variable of the Rule Variable called "rulename"
|
|
meta.rulename.text
|
|
|
|
// The text variable of the Rule Variable referenced to by rules.latest()
|
|
meta.latest().text
|
|
|
|
// The text (read-only) variable of the current grammar rule
|
|
meta.current().text
|
|
</pre>
|
|
|
|
<h1><a name="SI4" id="SI4">4 Semantic Interpretation
|
|
Grammars</a></h1>
|
|
|
|
<h2><a name="SI4.1" id="SI4.1">4.1 Semantic Interpretation
|
|
Grammars</a></h2>This specification defines a Semantic
|
|
Interpretation Grammar to be a Speech Recognition Grammar as
|
|
defined by [<a href="#refSRGS">SRGS</a>] that
|
|
|
|
<ul>
|
|
|
|
<li>has the tag-format value of <code>semantics/1.0</code> or
|
|
<code>semantics/1.0-literals</code></li>
|
|
|
|
<li>processes the contents of the tags as specified in this
|
|
specification</li>
|
|
|
|
<li>extends the use of the <code><tag></code> element to
|
|
the grammar header for the purpose of setting global
|
|
variables</li>
|
|
|
|
</ul>
|
|
|
|
<h2><a name="SI4.2" id="SI4.2">4.2 Global Variable Declarations
|
|
and Initialization</a></h2>
|
|
|
|
<p>The header of an [<a href="#refSRGS">SRGS</a>] grammar may
|
|
contain one or more global SI Tags. In grammars using the Script
|
|
tag syntax, these tags are executed before any of the SI Tags in
|
|
the matching grammar rules are evaluated. There are no ordering
|
|
constraints between SI Tags and other valid SRGS grammar header
|
|
items (see section 4.1 of [<a href="#refSRGS">SRGS</a>]). Global
|
|
tags are ignored in grammars using the String Literal tag
|
|
syntax.</p>
|
|
|
|
<p>The SI Tags are evaluated only once in a global scope that
|
|
will be shared by all evaluations (see section <a href="#SI6.3">6.3</a>)</p>
|
|
|
|
<p>Whereas all evaluations for SI Tags in flat parse lists for
|
|
matching rules have access to the global scope for reading only,
|
|
the SI Tags in the grammar header have write access to the global
|
|
scope. This is the primary function of these tags: to initialize
|
|
the global scope for use in the SI Tags.</p>
|
|
|
|
<h5 class="qualif">Examples:</h5>
|
|
|
|
<h5>XML Form</h5>
|
|
|
|
<p>In the XML Form, global SI Tags are SI Tags that appear
|
|
outside all rules in the grammar header and before the first
|
|
rule.</p>
|
|
<pre class="xml">
|
|
|
|
<grammar version="1.0" xmlns="http://www.w3.org/2001/06/grammar"
|
|
xml:lang="en-US" tag-format="semantics/1.0" root="rule">
|
|
<tag>var x=1;</tag>
|
|
<tag>var y='abcd';</tag>
|
|
<rule id="rule">
|
|
<one-of>
|
|
|
|
<item>yes</item>
|
|
<item>no</item>
|
|
</one-of>
|
|
</rule>
|
|
</grammar>
|
|
|
|
</pre>
|
|
|
|
<h5>ABNF Form</h5>
|
|
|
|
<p>In the ABNF Form, global SI Tags are SI Tags followed by a
|
|
semicolon, that appear outside all rules in the grammar header
|
|
and before the first rule. Both tag delimiting syntaxes are
|
|
illustrated in the example.</p>
|
|
<pre class="abnf">
|
|
#ABNF 1.0;
|
|
language en-US;
|
|
tag-format <semantics/1.0>;
|
|
root $rule;
|
|
{var x=1;};
|
|
{!{var y='abcd';}!};
|
|
$rule = yes | no;
|
|
</pre>
|
|
|
|
<h1 id="L3226"><a name="SI5" id="SI5">5 Default
|
|
Assignment</a></h1>
|
|
|
|
<p>For a given parse, if there is no SI Tag attached to the
|
|
expansion in the grammar rule that is used to match the
|
|
utterance, then the value for the <code>out</code> Rule Variable
|
|
is determined as follows. If there are no rule references in the
|
|
parse, the value for the text meta variable
|
|
(<code>meta.current().text</code>) is automatically copied into
|
|
the Rule Variable (which then becomes of type String). Otherwise,
|
|
the value of the Rule Variable of the last rule reference in the
|
|
parse (<code>rules.latest()</code>) is automatically copied into
|
|
the Rule Variable.</p>
|
|
|
|
<h5 class="qualif">Examples:</h5>
|
|
|
|
<p>For the following rule, <code>rules.drink</code> is either
|
|
"coke", "pepsi" or "coca cola". Similarly for
|
|
<code>meta.drink.text</code>.</p>
|
|
|
|
<pre class="xml">
|
|
<rule id="drink">
|
|
<one-of>
|
|
<item>coke</item>
|
|
<item>pepsi</item>
|
|
|
|
<item>coca cola</item>
|
|
</one-of>
|
|
</rule>
|
|
</pre>
|
|
|
|
<p>For the following rule, there is an String Literal tag
|
|
associated with "coca cola" and hence <code>rules.drink</code> is
|
|
either "coke" or "pepsi". However, <code>meta.drink.text</code>
|
|
|
|
is either "coke", "coca cola", or "pepsi".</p>
|
|
|
|
<pre class="xml">
|
|
<rule id="drink">
|
|
<one-of>
|
|
<item>coke</item>
|
|
|
|
<item>pepsi</item>
|
|
<item>coca cola<tag>coke</tag></item>
|
|
</one-of>
|
|
</rule>
|
|
|
|
</pre>
|
|
|
|
<p>For the following grammar, the utterance "I want to fly to
|
|
Boston" will return the result "BOS".</p>
|
|
|
|
<pre class="xml">
|
|
<grammar version="1.0" xmlns="http://www.w3.org/2001/06/grammar"
|
|
xml:lang="en-US" tag-format="semantics/1.0-literals" root="flight">
|
|
<rule id="flight" scope="public">
|
|
I want to fly to
|
|
<ruleref uri="#airports"/>
|
|
|
|
</rule>
|
|
<rule id="airports" scope="private">
|
|
<one-of>
|
|
<item><ruleref uri="#USairport"/></item>
|
|
<item><ruleref uri="#otherairport"/></item>
|
|
|
|
</one-of>
|
|
</rule>
|
|
<rule id="USairport" scope="private">
|
|
<one-of>
|
|
<item>Boston<tag>BOS</tag></item>
|
|
|
|
<item>New York<tag>JFK</tag></item>
|
|
<item>Chicago<tag>ORD</tag></item>
|
|
</one-of>
|
|
|
|
</rule>
|
|
<rule id="otherairport" scope="private">
|
|
<one-of>
|
|
<item>Brussels<tag>BRU</tag></item>
|
|
|
|
<item>Paris<tag>CDG</tag></item>
|
|
<item>Rome<tag>FCO</tag></item>
|
|
</one-of>
|
|
|
|
</rule>
|
|
</grammar>
|
|
</pre>
|
|
|
|
<p>Note that the default assignment has been designed to handle
|
|
the simplest but most frequent cases only. It cannot cope with
|
|
combining information from different rule references. For
|
|
example, the grammar below would return the information about the
|
|
last airport only, not about both airports. For the following
|
|
grammar, the utterance "I want to fly from Chicago to Boston"
|
|
will return the result "BOS".</p>
|
|
<pre class="xml">
|
|
<grammar version="1.0" xmlns="http://www.w3.org/2001/06/grammar"
|
|
xml:lang="en-US" tag-format="semantics/1.0-literals" root="flight">
|
|
<rule id="flight" scope="public">
|
|
|
|
I want to fly from
|
|
<one-of>
|
|
<item><ruleref uri="#USairport"/></item>
|
|
<item><ruleref uri="#otherairport"/></item>
|
|
</one-of>
|
|
|
|
to
|
|
<one-of>
|
|
<item><ruleref uri="#USairport "/></item>
|
|
<item><ruleref uri="#otherairport"/></item>
|
|
</one-of>
|
|
|
|
</rule>
|
|
<rule id="USairport" scope="private">
|
|
<one-of>
|
|
<item>Boston<tag>BOS</tag></item>
|
|
|
|
<item>New York<tag>JFK</tag></item>
|
|
<item>Chicago<tag>ORD</tag></item>
|
|
</one-of>
|
|
|
|
</rule>
|
|
<rule id="otherairport" scope="private">
|
|
<one-of>
|
|
<item>Brussels<tag>BRU</tag></item>
|
|
|
|
<item>Paris<tag>CDG</tag></item>
|
|
<item>Rome<tag>FCO</tag></item>
|
|
</one-of>
|
|
|
|
</rule>
|
|
</grammar>
|
|
</pre>
|
|
|
|
<p>In order to make this grammar return both airports, one would
|
|
have to use the Script tag syntax, as shown below. This
|
|
functionality cannot be achieved by relying only on literal tags
|
|
and default assignments.</p>
|
|
<pre class="xml">
|
|
<grammar version="1.0" xmlns="http://www.w3.org/2001/06/grammar"
|
|
xml:lang="en-US" tag-format="semantics/1.0" root="flight">
|
|
<rule id="flight" scope="public">
|
|
|
|
I want to fly from
|
|
<one-of>
|
|
<item>
|
|
<ruleref uri="http://www.example.com/places.grxml"/>
|
|
</item>
|
|
<item>
|
|
<ruleref uri="http://www.example.com/places.grxml#otherairport"/>
|
|
|
|
</item>
|
|
</one-of>
|
|
<tag>out.departure = rules.latest();</tag>
|
|
to
|
|
<one-of>
|
|
<item>
|
|
|
|
<ruleref uri="http://www.example.com/places.grxml"/>
|
|
</item>
|
|
<item>
|
|
<ruleref uri="http://www.example.com/places.grxml#otherairport"/>
|
|
</item>
|
|
</one-of>
|
|
|
|
<tag>out.arrival = rules.latest();</tag>
|
|
</rule>
|
|
</grammar>
|
|
</pre>
|
|
|
|
<p>Grammar http://www.example.com/places.grxml:</p>
|
|
<pre class="xml">
|
|
|
|
<grammar version="1.0" xmlns="http://www.w3.org/2001/06/grammar"
|
|
xml:lang="en-US" tag-format="semantics/1.0-literals" root="USairport">
|
|
<rule id="USairport" scope="public">
|
|
<one-of>
|
|
<item>Boston<tag>BOS</tag></item>
|
|
<item>New York<tag>JFK</tag></item>
|
|
|
|
<item>Chicago<tag>ORD</tag></item>
|
|
</one-of>
|
|
</rule>
|
|
<rule id="otherairport" scope="public">
|
|
|
|
<one-of>
|
|
<item>Brussels<tag>BRU</tag></item>
|
|
<item>Paris<tag>CDG</tag></item>
|
|
|
|
<item>Rome<tag>FCO</tag></item>
|
|
</one-of>
|
|
</rule>
|
|
</grammar>
|
|
</pre>
|
|
|
|
<h1 id="L3251"><a name="SI6" id="SI6">6 Visibility Rules and
|
|
Order of Tag Evaluation for SRGS Grammars</a></h1>
|
|
|
|
<p>This section defines the visibility rules and order of tag
|
|
evaluation for SI Tags used in the Speech Recognition Grammar
|
|
Format (ABNF and XML Form). When SI Tags are embedded in other
|
|
markup languages (e.g. in [<a href="#refNgrams">N-GRAM</a>]), the
|
|
visibility rules and order of evaluation may be defined
|
|
differently.</p>
|
|
|
|
<h2 id="L3256"><a name="SI6.1" id="SI6.1">6.1 Logical Parse
|
|
Structure</a></h2>
|
|
|
|
<p>After the initialization of the global scope (see section
|
|
<a href="#SI6.3">6.3</a>), the visibility rules and the order of
|
|
evaluation of semantic interpretation tags are defined in terms
|
|
of the logical parse structure as defined in Appendix H Logical
|
|
Parse Structure in [<a href="#refSRGS">SRGS</a>] .</p>
|
|
|
|
<p>Note that while this appendix is informative for the Speech
|
|
Recognition Grammar Specification, it is normative for the
|
|
Semantic Interpretation specification. This does not imply that
|
|
grammar processors must implement a logical parse structure, nor
|
|
that ambiguities or recursion should be handled in any specific
|
|
way over what is required for a conformant speech recognition
|
|
grammar processor. The Logical Parse Structure is only a means to
|
|
illustrate the order of evaluation and visibility rules for SI
|
|
Tags. Implementations are not required to expose the logical
|
|
structure and may use different internal representation as long
|
|
as these yield the results described here.</p>
|
|
|
|
<p>The Logical Parse Structure is a formal syntax for describing
|
|
the sequence and relation of tags and rule references to the
|
|
tokens that are input to the grammar processor.</p>
|
|
|
|
<p>The Logical Parse output is represented as an array of output
|
|
entities <b>en</b>, e.g. <b>[e1, e2, e3]</b>.</p>
|
|
|
|
<p>Output entities can be one out of three kinds:</p>
|
|
|
|
<ul>
|
|
|
|
<li>a token, represented as a string holding the literal
|
|
matching the input to the processor</li>
|
|
|
|
<li>a tag, represented as a SI Tag in curly braces</li>
|
|
|
|
<li>a rule reference, represented using the ABNF form for rule
|
|
references (see section 2.2 of [<a href="#refSRGS">SRGS</a>]),
|
|
followed by an array with the output entities generated from
|
|
that rule reference</li>
|
|
|
|
</ul>
|
|
|
|
<p>Appendix H in [<a href="#refSRGS">SRGS</a>] contains a full
|
|
description of how to create the logical parse on a grammar for a
|
|
given input to a grammar processor.</p>
|
|
|
|
<p>For the purpose of building the logical parse, all String
|
|
Literals are assumed to be converted into the equivalent SI
|
|
Script as defined in <a href="#SI3.2.3">3.2.3</a></p>
|
|
|
|
<h5 class="qualif">Examples:</h5>
|
|
|
|
<p>The sentence "turn the heating off" on the following XML Form
|
|
grammar</p>
|
|
|
|
<pre class="xml">
|
|
<grammar version="1.0" xmlns="http://www.w3.org/2001/06/grammar"
|
|
xml:lang="en-US" tag-format="semantics/1.0" root="command">
|
|
<rule id="command">
|
|
<one-of>
|
|
<item>set</item>
|
|
|
|
<item>turn</item>
|
|
</one-of>
|
|
<ruleref uri="#object"/>
|
|
<ruleref uri="#state"/>
|
|
<tag>out.o=rules.object; out.s=rules.state;</tag>
|
|
|
|
</rule>
|
|
<rule id="object">
|
|
<item repeat="0-1">the</item>
|
|
<one-of>
|
|
<item>
|
|
|
|
<one-of>
|
|
<item>heating</item>
|
|
<item>cooling</item>
|
|
</one-of>
|
|
<tag>out="airco";</tag>
|
|
|
|
</item>
|
|
<item>radio<tag>out="radio";</tag></item>
|
|
<item>lights<tag>out="lights";</tag></item>
|
|
|
|
</one-of>
|
|
</rule>
|
|
<rule id="state">
|
|
<one-of>
|
|
<item>to</item>
|
|
|
|
<item><ruleref special="NULL"/></item>
|
|
</one-of>
|
|
<one-of>
|
|
<item>on<tag>out="1";</tag></item>
|
|
|
|
<item>off<tag>out="0";</tag></item>
|
|
<item>warm<tag>out="w";</tag></item>
|
|
<item>cool<tag>out="c";</tag></item>
|
|
|
|
<item>cold<tag>out="c";</tag></item>
|
|
</one-of>
|
|
</rule>
|
|
</grammar>
|
|
</pre>
|
|
|
|
<p>or equivalent ABNF Form grammar</p>
|
|
<pre class="abnf">
|
|
#ABNF 1.0;
|
|
language en-US;
|
|
tag-format <semantics/1.0>;
|
|
root $command;
|
|
$command = (set | turn)
|
|
$object $state {out.o=rules.object; out.s=rules.state;};
|
|
$object = [the] (heating | cooling){out="airco";} | radio{out="radio";} |
|
|
lights{out="lights";};
|
|
$state = (to|$NULL) (on{out="1";} | off{out="0";} | warm{out="w";} |
|
|
cool{out="c";} | cold{out="c";});
|
|
</pre>
|
|
|
|
<p>will result in the logical parse</p>
|
|
<pre class="sample">
|
|
[$command [turn,
|
|
$object [the,
|
|
heating,
|
|
{out="airco";}],
|
|
$state [off,
|
|
{out="0";}],
|
|
{out.o=rules.object; out.s=rules.state;}]
|
|
]
|
|
|
|
</pre>
|
|
|
|
<h2 id="L3302"><a name="SI6.2" id="SI6.2">6.2 Flat Parse
|
|
List</a></h2>
|
|
|
|
<p>The logical parse structure is a tree-like structure that
|
|
shows all terminals, tags and rule references governed by a given
|
|
rule. This tree can also be represented in a flattened list of
|
|
parses, with one parse for every grammar rule application.</p>
|
|
|
|
<p>The flat parse for a given rule application is represented
|
|
as:</p>
|
|
|
|
<ul>
|
|
<li>the rule name followed by a sequence number in parenthesis
|
|
and a colon</li>
|
|
|
|
<li>a list of output entities</li>
|
|
</ul>
|
|
|
|
<p>The output entities are as in the logical parse structure,
|
|
except that rule references are represented without an array of
|
|
output entities but followed by a sequence number in
|
|
parenthesis.</p>
|
|
|
|
<h5 class="qualif">Examples:</h5>
|
|
|
|
<p>The equivalent flat parse list for the above example is:</p>
|
|
|
|
<pre class="sample">
|
|
$command(1): turn, $object(1),
|
|
$state(1), {out.o=rules.object; out.s=rules.state;}
|
|
$object(1): the, heating, {out="airco";}
|
|
$state(1): off, {out="0";}
|
|
</pre>
|
|
|
|
<p>The following example illustrates the use of the sequence
|
|
number for rules that are applied more than once. Consider the
|
|
grammar with String Literals, in XML Form:</p>
|
|
<pre class="xml">
|
|
<grammar version="1.0" xmlns="http://www.w3.org/2001/06/grammar"
|
|
xml:lang="en-US" tag-format="semantics/1.0-literals" root="a">
|
|
<rule id="a">
|
|
<item repeat="1-"><ruleref uri="#b"/></item>
|
|
|
|
<ruleref uri="#c"/>
|
|
<one-of>
|
|
<item>
|
|
<item repeat="0-1">t1</item>
|
|
<tag>tag1</tag>
|
|
|
|
</item>
|
|
<item>
|
|
<ruleref uri="#d"/>
|
|
<tag>tag2</tag>
|
|
</item>
|
|
|
|
</one-of>
|
|
</rule>
|
|
<rule id="b">
|
|
<one-of>
|
|
<item>t2</item>
|
|
|
|
<item>t3<tag>tag3</tag></item>
|
|
<item>t4</item>
|
|
</one-of>
|
|
</rule>
|
|
|
|
<rule id="c">
|
|
<item repeat="1-2">t5<tag>tag5</tag></item>
|
|
</rule>
|
|
<rule id="d">
|
|
|
|
t6 <ruleref uri="#c"/>
|
|
</rule>
|
|
</grammar>
|
|
</pre>
|
|
|
|
<p>or equivalently in ABNF Form:</p>
|
|
|
|
<pre class="abnf">
|
|
|
|
#ABNF 1.0;
|
|
language en-US;
|
|
tag-format <semantics/1.0-literals>;
|
|
root $a;
|
|
$a = ($b)<1-> $c (t1)<0-1> {tag1} | $d {tag2};
|
|
$b = t2 | t3 {tag3} | t4;
|
|
$c = (t5 {tag5})<1-2>;
|
|
$d = t6 $c;
|
|
</pre>
|
|
|
|
<p>Given the input "t2 t3 t5 t5", the logical parse structure
|
|
is:</p>
|
|
|
|
<pre class="sample">
|
|
[$a[ $b[t2], $b[t3, {tag3}],$c[t5, {tag5}, t5, {tag5}],{tag1}]
|
|
</pre>
|
|
|
|
<p>and the flat parse list is:</p>
|
|
<pre class="sample">
|
|
$a: $b(1), $b(2), $c(1), {tag1}
|
|
$b(1): t2
|
|
$b(2): t3, {tag3}
|
|
$c(1): t5, {tag5}, t5, {tag5}
|
|
</pre>
|
|
|
|
<h2 id="L3335"><a name="SI6.3" id="SI6.3">6.3 Scoping and
|
|
Visibility Rules for Script Tag Syntax Grammars</a></h2>These
|
|
scoping and visibility rules are defined on the basis of the flat
|
|
parse list as specified in section <a href="#SI6.2">6.2</a><br />
|
|
|
|
<h3 id="SI6.3.a"><a name="SI6.3.1" id="SI6.3.1">6.3.1 The Global
|
|
Scope</a></h3>
|
|
|
|
<p>Before evaluating any scripts in the flat parse list, a global
|
|
anonymous ECMAScript scope is created for the grammar. This
|
|
global scope is initialized by executing the scripts that are in
|
|
the global tags in the grammar header (see section <a href="#SI4.2">4.2</a>).</p>
|
|
|
|
<p>During evaluation of a script in the flat parse list, the
|
|
global scope is accessible for reading only.</p>
|
|
|
|
<p>Every script has only one global scope associated: the global
|
|
scope for the grammar in which the script appears. Scripts in
|
|
referenced rules that are located in a referenced external
|
|
grammar are thus executed with access to that referenced
|
|
grammar's global scope, and don't have access to the referencing
|
|
grammar's global scope.</p>
|
|
|
|
<p>The tags within a flat parse are executed in the order in
|
|
which they appear, left to right. The global tags (in the grammar
|
|
header) are executed in document order. See section <a href="#SI6.4">6.4</a> for details.</p>
|
|
|
|
<h3 id="SI6.3.b"><a name="SI6.3.2" id="SI6.3.2">6.3.2 Scope
|
|
Chains and Access to Variables</a></h3>
|
|
|
|
<p>For each flat parse, a new anonymous ECMAScript scope is
|
|
created that is a direct child of the global scope object for the
|
|
grammar in which the related rule is defined. The ECMAScript
|
|
scope chains thus always have the global scope (the scope of the
|
|
whole parse) as the top-level object, and the scope belonging to
|
|
the parse list as the successor.</p>
|
|
|
|
<p>Access to variables in tag executions are resolved with the
|
|
scope chain according to the ECMAScript rules (ES 10.1.4).</p>
|
|
|
|
<p>The variables object according to [<a href="#refECMA327">ECMA-327</a>] is the scope object created for this
|
|
rule. This means that local variables that are defined in tags
|
|
belonging to a rule reference are created in the scope object
|
|
that was created for this rule.</p>
|
|
|
|
<p>Before the first tag in a flat parse is executed, the
|
|
environment of a new scope is set up in the following way:</p>
|
|
|
|
<ul>
|
|
<li>The variable <code>out</code> is initialized to a new
|
|
object as constructed by the expression <code>new
|
|
Object()</code>.</li>
|
|
|
|
<li>The variable <code>rules</code> is initialized to a new
|
|
object as constructed by the expression <code>new
|
|
Object()</code>.</li>
|
|
|
|
<li>The variable <code>meta</code> is initialized to a new
|
|
object as constructed by the expression <code>new
|
|
Object()</code>.</li>
|
|
|
|
<li><code>meta.current().text</code> is initialized (read-only)
|
|
to the text variable of the current grammar rule.</li>
|
|
|
|
<li><code>meta.current().score</code> is initialized
|
|
(read-only) to the score value related to the current grammar
|
|
rule.</li>
|
|
|
|
<li><code>rules.latest()</code> returns undefined.</li>
|
|
|
|
<li><code>meta.latest()</code> returns undefined.</li>
|
|
</ul>
|
|
|
|
<p>When execution of the flat parse is finished, the scope object
|
|
of this flat parse is removed from the scope chain. The scope
|
|
belonging to the referencing flat parse is then updated in the
|
|
following way (replace <code>rulename</code> with the name of the
|
|
rule in what follows):</p>
|
|
|
|
<ul>
|
|
|
|
<li><code>rules.rulename</code> of the scope of the referencing
|
|
rule is set to the value of the variable <code>out</code> of
|
|
the child scope.</li>
|
|
|
|
<li><code>meta.rulename.text</code> of the scope of the
|
|
referencing rule is set to the concatenation of all terminals
|
|
within the rule reference.</li>
|
|
|
|
<li><code>meta.rulename.score</code> of the scope of the
|
|
referencing rule is set to score value for the referenced
|
|
rule.</li>
|
|
|
|
<li><code>rules.latest()</code> = <code>rules.rulename</code>
|
|
(both variables are in the scope of the referencing rule).</li>
|
|
|
|
<li><code>meta.latest().text</code> =
|
|
<code>meta.rulename.text</code> (both variables are in the
|
|
scope of the referencing rule).</li>
|
|
|
|
<li><code>meta.latest().score</code> =
|
|
<code>meta.rulename.score</code> (both variables are in the
|
|
scope of the referencing rule).</li>
|
|
|
|
</ul>If any of these variables already exist, they are
|
|
overwritten.
|
|
|
|
<p>Note: Whether or not the <code>out</code>, <code>rules</code>
|
|
|
|
and <code>meta</code> variables are enumerated when enumerating
|
|
the scope object is not defined by this specification and may
|
|
vary over implementations. Authors are discouraged to use
|
|
enumeration of the scope object.</p>
|
|
|
|
<h3 id="SI6.3.c"><a name="SI6.3.3" id="SI6.3.3">6.3.3
|
|
Visibility</a></h3>The consequences of these scoping rules are:
|
|
|
|
<ul>
|
|
|
|
<li>Within a parse list, results of previously executed rule
|
|
references that are a direct child of this list are available
|
|
by <code>rules.rulename</code> (where <code>rulename</code> is
|
|
the name of the referenced rule).</li>
|
|
|
|
<li>If a rule was referenced multiple times in the same scope,
|
|
the result of the last instantiation is visible.</li>
|
|
|
|
<li><code>rules.latest()</code> always refers to the result of
|
|
the previous reference in the current scope;
|
|
<code>meta.latest().text</code> refers to the corresponding
|
|
text utterance; and <code>meta.latest().score</code> refers to
|
|
the corresponding score value.</li>
|
|
|
|
</ul>
|
|
|
|
<h3 id="SI6.3.d"><a name="SI6.3.4" id="SI6.3.4">6.3.4 Global
|
|
Variables</a></h3>
|
|
|
|
<p>Since the global scope is read-only, assignments to global
|
|
variables are not allowed in SI Tags in rules. They are only
|
|
possible in the global SI Tags in the grammar header (see section
|
|
<a href="#SI4.2">4.2</a>)</p>
|
|
|
|
<h5 class="qualif">Examples:</h5>
|
|
|
|
<p>The following rule contains two Rule Variables associated with
|
|
the same rule "city". The XML Form is:</p>
|
|
<pre class="xml">
|
|
<rule id="fromto">
|
|
from
|
|
<ruleref uri="#city"/>
|
|
<tag>out.fromcity=rules.city.name;</tag>
|
|
|
|
to
|
|
<ruleref uri="#city"/>
|
|
<tag>out.tocity=meta.city.text;</tag>
|
|
</rule>
|
|
</pre>
|
|
|
|
<p>and the equivalent ABNF Form is:</p>
|
|
<pre class="abnf">
|
|
|
|
$fromto = from $city {out.fromcity=rules.city.name;} to
|
|
$city {out.tocity=meta.city.text;};
|
|
</pre>
|
|
|
|
<p>To determine which of the Rule Variable instances the tags
|
|
refer to, we can build the flat parse for <code>$fromto</code>,
|
|
which is always of the form:</p>
|
|
<pre class="sample">
|
|
$fromto: from, $city(1), {out.fromcity=rules.city.name;}, to,
|
|
$city(2), {out.tocity=meta.city.text;}
|
|
</pre>
|
|
|
|
<p>From this it follows that <code>rules.city.name</code> in the
|
|
first tag refers to the first Rule Variable
|
|
<code>rules.city</code> in the rule, and that the reference to
|
|
<code>meta.city.text</code> in the second tag is to the second
|
|
Rule Variable named <code>rules.city</code>.</p>
|
|
|
|
<p>In the following rule, the flat parse is depending on whether
|
|
the input matches the optional rule <code>b</code>. The XML Form
|
|
is:</p>
|
|
<pre class="xml">
|
|
<rule id="a">
|
|
<ruleref uri="#b"/>
|
|
<item repeat="0-1"><ruleref uri="#b"/></item>
|
|
|
|
<tag>out.x=rules.b.x;</tag>
|
|
</rule>
|
|
</pre>
|
|
|
|
<p>and the equivalent ABNF Form is:</p>
|
|
<pre class="abnf">
|
|
$a = $b [$b] {out.x=rules.b.x;};
|
|
</pre>
|
|
|
|
<p>The two possible flat parses are:</p>
|
|
<pre class="sample">
|
|
$a: $b(1), {out.x=rules.b.x;}
|
|
$a: $b(1), $b(2), {out.x=rules.b.x;}
|
|
</pre>
|
|
|
|
<p>The reference <code>rules.b.x</code> in the tag will thus
|
|
refer to either the first or the last rule <code>b</code>,
|
|
depending on whether the optional rule <code>b</code> was matched
|
|
in the input.</p>
|
|
|
|
<p>The SI Tag in the rule below contains a couple of references
|
|
to Rule Variables that are undefined since there is no Rule
|
|
Variable with that name before the tag in the flat parse. The XML
|
|
Form is:</p>
|
|
<pre class="xml">
|
|
<rule id="a">
|
|
<ruleref uri="#b"/>
|
|
<item repeat="0-1"><ruleref uri="#c"/></item>
|
|
<tag>out.x=rules.c; out.y=rules.d; out.z=rules.e;</tag>
|
|
|
|
<ruleref uri="#e"/>
|
|
</rule>
|
|
</pre>
|
|
|
|
<p>and the equivalent ABNF Form is:</p>
|
|
<pre class="abnf">
|
|
$a = $b [$c] {out.x=rules.c; out.y=rules.d; out.z=rules.e;} $e;
|
|
</pre>
|
|
|
|
<p>The two possible flat parses are:</p>
|
|
|
|
<pre class="sample">
|
|
$a: $b(1), {out.x=rules.c; out.y=rules.d; out.z=rules.e;}, $e(1)
|
|
$a: $b(1), $c(1), {out.x=rules.c; out.y=rules.d; out.z=rules.e;}, $e(1)
|
|
</pre>
|
|
|
|
<p>This means that:</p>
|
|
|
|
<ul>
|
|
<li><code>out.x</code> is undefined if rule <code>c</code>
|
|
|
|
didn't match in the utterance.</li>
|
|
|
|
<li><code>out.y</code> is undefined because rule <code>d</code>
|
|
is not in the rule expansion at all.</li>
|
|
|
|
<li><code>out.z</code> is undefined because rule <code>e</code>
|
|
|
|
doesn't appear before the tag.</li>
|
|
</ul>
|
|
|
|
<h2 id="L3391"><a name="SI6.4" id="SI6.4">6.4 Order of Tag
|
|
Execution for Script Tag Syntax Grammars</a></h2>
|
|
|
|
<p>Within a single SI Tag, the order of evaluation is determined
|
|
by [<a href="#refECMA327">ECMA-327</a>] for the evaluation of a
|
|
valid [<a href="#refECMA327">ECMA-327</a>] Program (ES 14).</p>
|
|
|
|
<p>All global SI Tags (in tags in the grammar header) are
|
|
executed once, before any SI Tags within a grammar rule are
|
|
executed (see section <a href="#SI4.2">4.2</a>).</p>
|
|
|
|
<p>The order of evaluating multiple SI Tags within a grammar rule
|
|
is the order in which the SI Tags appear in the flat parse list
|
|
for that rule application. The flat parse list also determines
|
|
how many SI elements will be generated from an SI Tag that occurs
|
|
in a grammar rule. Every SI Tag element in a flat parse list is
|
|
evaluated exactly once. The order of evaluating String Literals
|
|
is determined by the order in which the equivalent SI Tag appears
|
|
in the flat parse list (see section <a href="#SI6.2">6.2</a>).</p>
|
|
|
|
<p>The computation of the semantic value of a rule reference in a
|
|
flat parse list may occur at any time during the processing of
|
|
the entire logical parse structure, subject to the following
|
|
condition: the semantic value of a rule reference must be
|
|
computed before any SI Tag using that reference's value is
|
|
processed.</p>
|
|
|
|
<h5 class="qualif">Examples:</h5>
|
|
|
|
<p>Consider the following rules in XML Form:</p>
|
|
<pre class="xml">
|
|
<rule id="a">
|
|
<ruleref uri="#b"/>
|
|
<tag>out.y=rules.b.x;</tag>
|
|
|
|
<item repeat="0-1">
|
|
<ruleref uri="#b"/><tag>out.y=out.y+rules.b.x;</tag>
|
|
</item>
|
|
</rule>
|
|
<rule id="b">
|
|
foo
|
|
<tag>out.x=1;</tag>
|
|
|
|
<one-of>
|
|
<item>bar<tag>out.x=3;</tag></item>
|
|
<item>
|
|
<item repeat="1-">boo<tag>out.x=out.x+1;</tag></item>
|
|
|
|
</item>
|
|
</one-of>
|
|
</rule>
|
|
</pre>
|
|
|
|
<p>or equivalently in ABNF Form:</p>
|
|
<pre class="abnf">
|
|
$a = $b {out.y=rules.b.x;} [$b {out.y=out.y+rules.b.x;}];
|
|
$b = foo {out.x=1;} (bar {out.x=3;} | (boo {out.x=out.x+1;})<1->);
|
|
|
|
</pre>
|
|
|
|
<p>For the input "foo boo boo boo", the flat parse lists are:</p>
|
|
|
|
<pre class="sample">
|
|
$a: $b(1), {out.y=rules.b.x}
|
|
$b(1): foo, {out.x=1;}, boo, {out.x=out.x+1;}, boo, {out.x=out.x+1;},
|
|
boo, {out.x=out.x+1;}
|
|
</pre>
|
|
|
|
<p>and <code>out.y</code> evaluates to 4.</p>
|
|
|
|
<p>For the input "foo bar foo boo", the flat parse lists are:</p>
|
|
<pre class="sample">
|
|
$a: $b(1), {out.y=rules.b.x;}, $b(2), {out.y=out.y+rules.b.x;}
|
|
$b(1): foo, {out.x=1;}, bar, {out.x=3;}
|
|
$b(2): foo, {out.x=1;}, boo, {out.x=out.x+1;}
|
|
</pre>
|
|
|
|
<p>and <code>out.y</code> evaluates to 5.</p>
|
|
|
|
<h2 id="L3418"><a name="SI6.5" id="SI6.5">6.5 Examples</a></h2>
|
|
|
|
<p>The <code>rules.b.x</code> and <code>rules.c.x</code> refer to
|
|
the respective Rule Variable properties:</p>
|
|
|
|
<pre class="xml">
|
|
<rule id="a">
|
|
<ruleref uri="#b"/>
|
|
|
|
<ruleref uri="#c"/>
|
|
<tag>out.x = rules.b.x + rules.c.x;</tag>
|
|
</rule>
|
|
</pre>
|
|
|
|
<p>The <code>rules.c.x</code> causes a run-time error because it
|
|
is used to the left of rule <code>c</code>:</p>
|
|
|
|
<pre class="xml">
|
|
<rule id="a">
|
|
<ruleref uri="#b"/>
|
|
<tag>out.x = rules.b.x + rules.c.x;</tag>
|
|
<ruleref uri="#c"/>
|
|
</rule>
|
|
|
|
</pre>
|
|
|
|
<p>The <code>rules.b.x</code> evaluates to the <code>x</code>
|
|
|
|
property of <code>rules.b</code> if rule <code>b</code> is
|
|
matched on the input utterance. Otherwise it causes a run-time
|
|
error:</p>
|
|
|
|
<pre class="xml">
|
|
<rule id="a">
|
|
<item repeat="0-1"><ruleref uri="#b"/></item>
|
|
<ruleref uri="#c"/>
|
|
<tag>out.x = rules.b.x + rules.c.x;</tag>
|
|
|
|
</rule>
|
|
</pre>
|
|
|
|
<p>A safer way to write this rule could be (assuming
|
|
<code>x</code> is of type Number):</p>
|
|
|
|
<pre class="xml">
|
|
<rule id="a">
|
|
<tag>out.x=0;</tag>
|
|
|
|
<item repeat="0-1"><ruleref uri="#b"/><tag>out.x=rules.b.x;</tag></item>
|
|
<ruleref uri="#c"/>
|
|
<tag>out.x = out.x + rules.c.x;</tag>
|
|
</rule>
|
|
|
|
</pre>
|
|
|
|
<p>The <code>rules.b.x</code> evaluates to the last occurrence of
|
|
rule <code>b</code> in the repeat:</p>
|
|
|
|
<pre class="xml">
|
|
<rule id="a">
|
|
<item repeat="1-"><ruleref uri="#b"/></item>
|
|
|
|
<ruleref uri="#c"/>
|
|
<tag>out.x=rules.b.x+rules.c.x;</tag>
|
|
</rule>
|
|
</pre>
|
|
|
|
<p>If the purpose was to add or concatenate over each occurrence
|
|
of <code>rules.b</code>, it should be written as:</p>
|
|
|
|
<pre class="xml">
|
|
<rule id="a">
|
|
<item repeat="1-">
|
|
<ruleref uri="#b"/><tag>out.x=out.x+rules.b.x;</tag>
|
|
</item>
|
|
|
|
<ruleref uri="#c"/>
|
|
<tag>out.x=out.x+rules.c.x;</tag>
|
|
</rule>
|
|
</pre>
|
|
|
|
<p>The <code>rules.b</code> evaluates to the last occurrence of
|
|
<code>rules.b</code> in the <code>repeat="0-"</code> expansion,
|
|
if any, otherwise it is undefined:</p>
|
|
|
|
<pre class="xml">
|
|
<rule id="a">
|
|
<item repeat="0-"><ruleref uri="#b"/><ruleref uri="#d"/></item>
|
|
<ruleref uri="#c"/>
|
|
<tag>out.x=rules.b+rules.c.x;</tag>
|
|
|
|
</rule>
|
|
</pre>
|
|
|
|
<p>Either <code>rules.b.x</code> or <code>rules.c.x</code> will
|
|
cause a run-time error depending on the input utterance:</p>
|
|
<pre class="xml">
|
|
<rule id="a">
|
|
|
|
<one-of>
|
|
<item><ruleref uri="#b"/></item>
|
|
<item><ruleref uri="#c"/></item>
|
|
</one-of>
|
|
<tag>out.x=rules.b.x+rules.c.x;</tag>
|
|
|
|
</rule>
|
|
</pre>
|
|
|
|
<p>This could be better written as:</p>
|
|
<pre class="xml">
|
|
<rule id="a">
|
|
<one-of>
|
|
<item><ruleref uri="#b"/><tag>out.x=rules.b.x;</tag></item>
|
|
|
|
<item><ruleref uri="#c"/><tag>out.x=rules.c.x;</tag></item>
|
|
</one-of>
|
|
</rule>
|
|
</pre>
|
|
|
|
<p>The <code>rules.b.x</code> refers to whichever
|
|
<code>rules.b</code> actually matched:</p>
|
|
|
|
<pre class="xml">
|
|
<rule id="a">
|
|
<one-of>
|
|
<item><ruleref uri="#b"/> a</item>
|
|
<item>a <ruleref uri="#b"/></item>
|
|
|
|
</one-of>
|
|
<ruleref uri="#c"/>
|
|
<tag>out.x=rules.b.x+rules.c.x;</tag>
|
|
</rule>
|
|
</pre>
|
|
|
|
<p>One of the operands to every addition causes a run-time error
|
|
here depending on the input utterance:</p>
|
|
|
|
<pre class="xml">
|
|
<rule id="a">
|
|
<one-of>
|
|
<item><ruleref uri="#b"/></item>
|
|
<item><ruleref uri="#c"/></item>
|
|
|
|
</one-of>
|
|
<one-of>
|
|
<item><ruleref uri="#d"/></item>
|
|
<item><ruleref uri="#e"/></item>
|
|
</one-of>
|
|
|
|
<tag>out.x=(rules.b.x+rules.c.x) * (rules.d.x+rules.e.x);</tag>
|
|
</rule>
|
|
</pre>
|
|
|
|
<p>This rule can be better written as:</p>
|
|
|
|
<pre class="xml">
|
|
<rule id="a">
|
|
|
|
<one-of>
|
|
<item><ruleref uri="#b"/><tag>out.x=rules.b.x;</tag></item>
|
|
<item><ruleref uri="#c"/><tag>out.x=rules.c.x;</tag></item>
|
|
|
|
</one-of>
|
|
<one-of>
|
|
<item><ruleref uri="#d"/><tag>out.x=out.x*rules.d.x;</tag></item>
|
|
<item><ruleref uri="#e"/><tag>out.x=out.x*rules.e.x;</tag></item>
|
|
|
|
</one-of>
|
|
</rule>
|
|
</pre>
|
|
|
|
<p>Evaluation of <code>rules.b.x</code> always causes a run-time
|
|
error because the expression will be evaluated only when rule
|
|
<code>c</code> matches, not rule <code>b</code>. (When rule
|
|
<code>b</code> matches, the default assignment would cause
|
|
<code>out=meta.b.text</code>).</p>
|
|
|
|
<pre class="xml">
|
|
<rule id="a">
|
|
<one-of>
|
|
<item><ruleref uri="#b"/></item>
|
|
<item><ruleref uri="#c"/><tag>out.x=rules.b.x+rules.c.x;</tag></item>
|
|
|
|
</one-of>
|
|
</rule>
|
|
</pre>
|
|
|
|
<p>A more useful rule could be:</p>
|
|
<pre class="xml">
|
|
<rule id="a">
|
|
<one-of>
|
|
|
|
<item><ruleref uri="#b"/><tag>out.x=rules.b.x;</tag></item>
|
|
<item><ruleref uri="#c"/><tag>out.x=rules.c.x;</tag></item>
|
|
</one-of>
|
|
|
|
</rule>
|
|
</pre>
|
|
|
|
<p>The expression is only evaluated if rule <code>c</code>
|
|
matches; in that case both <code>rules.b</code> and
|
|
<code>rules.c</code> are defined:</p>
|
|
|
|
<pre class="xml">
|
|
<rule id="a">
|
|
<ruleref uri="#b"/>
|
|
<item repeat="0-1">
|
|
<ruleref uri="#c"/>
|
|
<tag>out.x=rules.b.x+rules.c.x;</tag>
|
|
|
|
</item>
|
|
</rule>
|
|
</pre>
|
|
|
|
<p>The expression is evaluated for every occurrence of rule
|
|
<code>c</code>. Note that this will actually result in
|
|
<code>rules.b.x</code> to be added to <code>out.x</code> for the
|
|
last occurrence of rule <code>c</code> because every evaluation
|
|
will overwrite the previous result.</p>
|
|
|
|
<pre class="xml">
|
|
<rule id="a">
|
|
<ruleref uri="#b"/>
|
|
<item repeat="1-">
|
|
<ruleref uri="#c"/>
|
|
<tag>out.x = rules.b.x + rules.c.x;</tag>
|
|
|
|
</item>
|
|
</rule>
|
|
</pre>
|
|
|
|
<p>Same effect as previous example except that now the expression
|
|
is not evaluated if rule <code>c</code> did not match once.</p>
|
|
<pre class="xml">
|
|
<rule id="a">
|
|
|
|
<ruleref uri="#b"/>
|
|
<item repeat="0-">
|
|
<ruleref uri="#c"/>
|
|
<tag>out.x = rules.b.x + rules.c.x;</tag>
|
|
</item>
|
|
|
|
</rule>
|
|
</pre>
|
|
|
|
<p>These rules do the obvious concatenation of digits. Note that
|
|
the <code>ds</code> property is first initialized to
|
|
<code>""</code> because otherwise in the first evaluation of the
|
|
expression, <code>ds</code> would be undefined and would cause a
|
|
run-time error:</p>
|
|
|
|
<pre class="xml">
|
|
<rule id="digits">
|
|
<tag>out.ds="";</tag>
|
|
<item repeat="1-">
|
|
<ruleref uri="#digit"/>
|
|
<tag>out.ds = out.ds + rules.digit;</tag>
|
|
|
|
</item>
|
|
</rule>
|
|
<rule id="digit">
|
|
<one-of>
|
|
<item>"0"</item>
|
|
<item>"1"</item>
|
|
|
|
<item>"2"</item>
|
|
<item>"3"</item>
|
|
<item>"4"</item>
|
|
<item>"5"</item>
|
|
|
|
<item>"6"</item>
|
|
<item>"7"</item>
|
|
<item>"8"</item>
|
|
<item>"9"</item>
|
|
|
|
</one-of>
|
|
</rule>
|
|
</pre>
|
|
|
|
<p>The <code>rules.latest()</code> resolves to
|
|
<code>rules.c</code>:</p>
|
|
|
|
<pre class="xml">
|
|
|
|
<rule id="a">
|
|
<ruleref uri="#b"/>
|
|
<ruleref uri="#c"/>
|
|
<tag>out=rules.latest();</tag>
|
|
</rule>
|
|
</pre>
|
|
|
|
<p>The <code>rules.latest()</code> resolves to
|
|
<code>rules.b</code>:</p>
|
|
<pre class="xml">
|
|
<rule id="a">
|
|
<ruleref uri="#c"/>
|
|
<ruleref uri="#b"/>
|
|
|
|
<tag>out=rules.latest();</tag>
|
|
</rule>
|
|
</pre>
|
|
|
|
<p>The <code>rules.latest()</code> returns
|
|
<code>undefined</code>:</p>
|
|
|
|
<pre class="xml">
|
|
<rule id="a">
|
|
b c
|
|
<tag>out=rules.latest();</tag>
|
|
</rule>
|
|
</pre>
|
|
|
|
<p>If rule <code>b</code> matches, <code>rules.latest()</code>
|
|
|
|
resolves to <code>rules.b</code>. If rule <code>c</code> matches,
|
|
<code>rules.latest()</code> resolves to <code>rules.c</code>:</p>
|
|
<pre class="xml">
|
|
<rule id="x">
|
|
|
|
<ruleref uri="#a"/>
|
|
<one-of>
|
|
<item><ruleref uri="#b"/></item>
|
|
<item><ruleref uri="#c"/></item>
|
|
</one-of>
|
|
|
|
<tag>out=rules.latest();</tag>
|
|
</rule>
|
|
</pre>
|
|
|
|
<p>This is equivalent to:</p>
|
|
|
|
<pre class="xml">
|
|
<rule id="x">
|
|
|
|
<ruleref uri="#a"/>
|
|
<one-of>
|
|
<item><ruleref uri="#b"/><tag>out=rules.latest();</tag></item>
|
|
<item><ruleref uri="#c"/><tag>out=rules.latest();</tag></item>
|
|
|
|
</one-of>
|
|
</rule>
|
|
</pre>
|
|
|
|
<p>The <code>rules.latest()</code> resolves to
|
|
<code>rules.b</code>, if rule <code>b</code> matches, if not, it
|
|
resolves to <code>rules.a</code>:</p>
|
|
|
|
<pre class="xml">
|
|
<rule id="x">
|
|
<ruleref uri="#a"/>
|
|
<item repeat="0-1"><ruleref uri="#b"/></item>
|
|
<tag>out=rules.latest();</tag>
|
|
|
|
</rule>
|
|
</pre>
|
|
|
|
<p>The effect is equivalent to:</p>
|
|
<pre class="xml">
|
|
<rule id="x">
|
|
<ruleref uri="#a"/><tag>out=rules.latest();</tag>
|
|
|
|
<item repeat="0-1"><ruleref uri="#b"/><tag>out=rules.latest();</tag></item>
|
|
</rule>
|
|
</pre>
|
|
|
|
<p>The <code>rules.latest()</code> resolves to the last
|
|
occurrence of <code>rules.a</code>:</p>
|
|
|
|
<pre class="xml">
|
|
<rule id="x">
|
|
<item repeat="1-"><ruleref uri="#a"/></item>
|
|
<tag>out=rules.latest();</tag>
|
|
</rule>
|
|
|
|
</pre>
|
|
|
|
<p>The effect is equivalent to:</p>
|
|
|
|
<pre class="xml">
|
|
<rule id="x">
|
|
<item repeat="1-"><ruleref uri="#a"/><tag>out=rules.latest();</tag></item>
|
|
|
|
</rule>
|
|
</pre>
|
|
|
|
<h1><a id="SI7" name="SI7">7 Using Semantic Interpretation to
|
|
Generate XML Results</a></h1>
|
|
|
|
<p>Semantic Interpretation processors may be used in environments
|
|
where a return result is expected in [<a href="#refXML">XML</a>]
|
|
format (for example, those supporting [<a href="#refEMMA">EMMA</a>]).</p>
|
|
|
|
<p>If returning XML results, the following serialization rules
|
|
must be used to generate an XML fragment from the Semantic
|
|
Interpretation process. Notice that these serialization rules
|
|
apply to semantic values generated by authored SI Tags during SI
|
|
processing, and do not preclude the addition of further
|
|
information into the XML result by an individual SI processor
|
|
(for example, recognizer annotations corresponding to acoustic
|
|
confidence scores or other such information). This specification
|
|
does not define the XML documents in which the generated fragment
|
|
can be embedded.</p>
|
|
|
|
<p>The serialization into XML has been designed as a convenient
|
|
mechanism to generate XML fragments directly from SI grammars. It
|
|
has not been designed as a generic conversion mechanism from
|
|
[<a href="#refECMA327">ECMA-327</a>] objects into XML fragments.
|
|
It is not a generic conversion mechanism for at least the
|
|
following reasons:</p>
|
|
|
|
<ul>
|
|
<li>Not all valid ECMAScript names are valid XML Names; invalid
|
|
XML Names can cause the conversion to fail.</li>
|
|
|
|
<li>ECMAScript Objects can contain circular references.
|
|
Handling of these is platform specific.</li>
|
|
|
|
<li>Not all information in an ECMAScript Object is serialized;
|
|
in particular, Object type information and
|
|
<code>DontEnum</code> properties are not serialized.</li>
|
|
|
|
<li>The conversion makes use of some reserved names. Using
|
|
these names in different ways can cause unexpected
|
|
results.</li>
|
|
|
|
<li>The conversion is not reversible.</li>
|
|
|
|
<li>The information in an ECMAScript Object is not ordered,
|
|
hence the order of the resulting XML elements is not
|
|
defined.</li>
|
|
|
|
</ul>
|
|
|
|
<h2><a name="SI7.1" id="SI7.1">7.1 Serialization of an ECMAScript
|
|
Result into an XML Fragment</a></h2>
|
|
|
|
<p>The serialization of the ECMAScript result into an XML
|
|
fragment is governed by the following transformations rules:</p>
|
|
|
|
<ol>
|
|
<li>If the ECMAScript top-level Rule Variable is not an
|
|
<code>Object</code> but a simple scalar type (String, Number,
|
|
Boolean, Null or Undefined) then the resulting XML fragment
|
|
only consists of character data without any mark-up. The
|
|
character data will be the value of the top-level Rule Variable
|
|
as if the <code>ToString()</code> operation had been performed
|
|
on an argument of this type (e.g., for Boolean, the result
|
|
would be <code>true</code> or <code>false</code>).</li>
|
|
|
|
<li>Each property (see note below) in the ECMAScript top-level
|
|
Rule Variable becomes an XML element. The name of the element
|
|
will be the same as the name of the property.</li>
|
|
|
|
<li>If the value of the property is a simple scalar type
|
|
(String, Number, Boolean, Null or Undefined) then the character
|
|
data content of the XML element will be the value of this
|
|
property as if the <code>ToString()</code> operation had been
|
|
performed on an argument of this type.</li>
|
|
|
|
<li>If the property is of type Object, then each child property
|
|
of this object becomes a child element, and the contents of
|
|
these child elements are in turn processed.</li>
|
|
|
|
<li>Indexed elements of an <code>Array</code> object (e.g.
|
|
<code>a[0]</code>, <code>a[1]</code>. etc.) become XML child
|
|
elements with name <code><item></code>. Each
|
|
<code><item></code> element has an attribute named
|
|
<code>index</code>, which is the index of the corresponding
|
|
element in the array. In addition, the XML element containing
|
|
the <code><item></code> elements includes an attribute
|
|
named <code>length</code>, whose value is given by the length
|
|
property of the ECMAScript Array object. Any other properties
|
|
of an Array object, for instance the keys of an associative
|
|
array (e.g. <code>a["prop"]</code>), are subject to the same
|
|
transformation rules as the regular properties of an object. In
|
|
a sparse array, only those elements which hold defined values
|
|
will be serialized.</li>
|
|
|
|
<li>Properties with the name <code>_attributes</code>,
|
|
<code>_value</code>, <code>_nsdecl</code> and
|
|
<code>_nsprefix</code> will be treated according to the rules
|
|
described in the sections below.</li>
|
|
</ol>
|
|
|
|
<p>Notes:</p>
|
|
|
|
<ul>
|
|
<li>Properties which have the <code>DontEnum</code> attribute
|
|
(see ES 8.6.1) are not serialized. This prevents functions and
|
|
built-in properties from being serialized.</li>
|
|
|
|
<li>The values of properties of type String may contain special
|
|
characters such as < and &, which could be erroneously
|
|
treated as the start of markup by XML processors. An SI
|
|
processor can use CDATA sections or character escaping to avoid
|
|
this problem.</li>
|
|
|
|
<li>It is an error to transform an ECMAScript object into XML
|
|
that contains properties with names that are not allowed in
|
|
XML. This can occur when a property of a Rule Variable has a
|
|
name that is not a legal name for an XML element.</li>
|
|
|
|
<li>It is possible for circular references to exist between
|
|
ECMAScript objects, for example, if an object contains a
|
|
property that references itself. The handling of circular
|
|
references is platform specific.</li>
|
|
|
|
<li>As a consequence of these transformation rules, the XML
|
|
fragment resulting from grammars using the String Literal tag
|
|
syntax will contain character data corresponding to the
|
|
top-level Rule Variable string value with no additional
|
|
elements or attributes.</li>
|
|
|
|
<li>As a consequence of these transformation rules, if the
|
|
top-level Rule Variable is an <code>Array</code> object, the
|
|
<code>length</code> attribute will not be present because there
|
|
will be no XML element containing the <code><item></code>
|
|
|
|
child elements.</li>
|
|
</ul>
|
|
|
|
<h5 class="qualif">Examples:</h5>
|
|
|
|
<p>Following the above principles, to take the top-level Rule
|
|
Variable with the properties drink and pizza of the example
|
|
grammar in section <a href="#SI8">8</a>:</p>
|
|
|
|
<pre class="sample">
|
|
{
|
|
drink: {
|
|
liquid:"coke",
|
|
drinksize:"medium"},
|
|
pizza: {
|
|
number: "3",
|
|
pizzasize: "large",
|
|
topping: [ "pepperoni" "mushrooms" ]
|
|
}
|
|
}
|
|
</pre>
|
|
|
|
<p>SI processing in an XML environment would generate the
|
|
following document:</p>
|
|
<pre class="sample">
|
|
<drink>
|
|
<liquid>coke</liquid>
|
|
|
|
<drinksize>medium</drinksize>
|
|
</drink>
|
|
<pizza>
|
|
<number>3</number>
|
|
<pizzasize>large</pizzasize>
|
|
|
|
<topping length="2">
|
|
<item index="0">pepperoni</item>
|
|
<item index="1">mushrooms</item>
|
|
</topping>
|
|
</pizza>
|
|
|
|
</pre>
|
|
|
|
<p>The following example ECMAScript object would cause an error
|
|
because the <code>$size$</code> property while a valid name in
|
|
ECMAScript is not a valid name for an XML Element:</p>
|
|
<!-- added class="sample -->
|
|
<pre class="sample">
|
|
{
|
|
drink: {
|
|
liquid:"coke",
|
|
$size$:"medium"}
|
|
}
|
|
</pre>
|
|
|
|
<h2><a name="SI7.2" id="SI7.2">7.2 Use of _attributes and
|
|
_value</a></h2>
|
|
|
|
<p>Variables named <code>_attributes</code> and
|
|
<code>_value</code> can be created and used by the author to
|
|
enable the generation of richer XML results, including the
|
|
following structures:</p>
|
|
|
|
<ul>
|
|
|
|
<li>XML elements that contain both elements and character
|
|
data.</li>
|
|
|
|
<li>XML elements that contain attributes.</li>
|
|
|
|
<li>XML elements containing a mixture of elements, attributes
|
|
and character data.</li>
|
|
</ul>
|
|
|
|
<p>The <code>_attributes</code> object is used to hold property
|
|
name/value pairs which will be rendered as XML attributes of the
|
|
object which contains <code>_attributes</code>.</p>
|
|
|
|
<p>The <code>_value</code> variable is used to hold a scalar
|
|
value for character data contained in an element or to hold the
|
|
value of an attribute.</p>
|
|
|
|
<p>Semantic Interpretation processors treat these objects in the
|
|
following way:</p>
|
|
|
|
<ol>
|
|
<li>Properties specified in the <code>_attributes</code> object
|
|
are rendered as XML attributes of the containing object.</li>
|
|
|
|
<li>The value of <code>_value</code> is treated as character
|
|
data content of the containing object or the value of an
|
|
attribute if the containing object is a child of
|
|
<code>_attributes</code>.</li>
|
|
</ol>
|
|
|
|
<p>If the value of <code>_value</code> is not a scalar type, the
|
|
<code>ToString()</code> operation is performed to generate a
|
|
string value.</p>It is an error to transform an ECMAScript object
|
|
into XML, that contains properties with names that are not
|
|
allowed in XML. This can occur when a property name in an
|
|
<code>_attribute</code> has a name that is not a legal name for
|
|
an XML attribute.
|
|
|
|
<h5 class="qualif">Examples:</h5>
|
|
|
|
<p>The following ECMAScript object:</p>
|
|
<!-- added class="sample -->
|
|
<pre class="sample">
|
|
{
|
|
martini: {
|
|
gin: {
|
|
_value: "Bombay Sapphire",
|
|
_attributes {
|
|
ratio: 8
|
|
}
|
|
},
|
|
vermouth: {
|
|
_value: "Noilly Prat" ,
|
|
_attributes {
|
|
ratio: 1
|
|
}
|
|
},
|
|
_attributes {
|
|
method: "shaken"
|
|
}
|
|
}
|
|
}
|
|
</pre>
|
|
|
|
<p>would generate the following XML result:</p>
|
|
<!-- added class="sample -->
|
|
<pre class="sample">
|
|
|
|
...
|
|
<martini method="shaken">
|
|
<gin ratio="8">Bombay Sapphire</gin>
|
|
<vermouth ratio="1">Noilly Prat</vermouth>
|
|
</martini>
|
|
...
|
|
</pre>
|
|
|
|
<h2><a name="SI7.3" id="SI7.3">7.3 Namespaces</a></h2>
|
|
|
|
<p>The object named <code>_nsdecl</code> is used to declare a
|
|
namespace [<a href="#refXMLNames">XML-NAMES</a>] in an element.
|
|
The property named <code>_nsprefix</code> enables the SI author
|
|
to associate an XML element or attribute with a particular
|
|
namespace.</p>
|
|
|
|
<p>When an object contains the <code>_nsdecl</code> property, the
|
|
namespace declaration is attached to the resultant XML serialized
|
|
element for this object. The <code>_prefix</code> property of
|
|
<code>_nsdecl</code> indicates the namespace prefix and the
|
|
<code>_name</code> property of <code>_nsdecl</code> indicates the
|
|
corresponding namespace name (usually a URI reference). If the
|
|
<code>_prefix</code> property is an empty string, the default
|
|
namespace is declared. If both <code>_prefix</code> and
|
|
<code>_name</code> are empty strings, the namespace declaration
|
|
<code>xmlns=""</code> applies.</p>
|
|
|
|
<p>When an <code>Array</code> object contains the
|
|
<code>_nsprefix</code> property, the prefix also applies to the
|
|
automatically generated <code><item></code> elements and
|
|
<code>length</code> and <code>index</code> attributes.</p>
|
|
|
|
<p>Note that this transformation produces an XML fragment - see
|
|
[<a href="#refXMLNames">XML-NAMES</a>] for rules on valid
|
|
namespace usage in XML.</p>
|
|
|
|
<h5 class="qualif">Informative Note:</h5>The
|
|
<code>_nsprefix</code> can be used for example to generate XML
|
|
attributes such as <code>emma:hook</code> or
|
|
<code>emma:tokens</code> when generating XML fragments to be
|
|
embedded in EMMA documents. See Appendix C of the [<a href="#refEMMA">EMMA</a>] specification for more information and
|
|
examples. The namespace declaration with <code>_nsdecl</code> may
|
|
not be needed when provided by the XML document in which the
|
|
fragment will be embedded.
|
|
|
|
<h5 class="qualif">Examples:</h5>
|
|
|
|
<p>The following ECMAScript object:</p>
|
|
<!-- added class="sample -->
|
|
<pre class="sample">
|
|
{
|
|
drink: {
|
|
_nsdecl: {
|
|
_prefix:"n1",
|
|
_name:"http://www.example.com/n1"
|
|
},
|
|
_nsprefix:"n1",
|
|
liquid: {
|
|
_nsdecl: {
|
|
_prefix:"n2",
|
|
_name:"http://www.example.com/n2"
|
|
},
|
|
_attributes: {
|
|
color: {
|
|
_nsprefix:"n2",
|
|
_value:"black"
|
|
}
|
|
},
|
|
_value:"coke"
|
|
},
|
|
size:"medium"
|
|
}
|
|
}
|
|
</pre>
|
|
|
|
<p>would generate the following XML result:</p>
|
|
<!-- added class="sample -->
|
|
<pre class="sample">
|
|
|
|
<n1:drink xmlns:n1="http://www.example.com/n1">
|
|
<liquid n2:color="black" xmlns:n2="http://www.example.com/n2">coke</liquid>
|
|
<size>medium</size>
|
|
</n1:drink>
|
|
</pre>
|
|
|
|
<p>Note that the <code>_nsprefix</code> property only applies to
|
|
its parent object and hence neither the
|
|
<code><liquid></code> element nor the
|
|
<code><size></code> element are associated with a namespace
|
|
in this fragment.</p>
|
|
|
|
<h1 id="L3425"><a name="SI8" id="SI8">8 Example Grammars with
|
|
Semantic Interpretation Tags</a></h1>
|
|
|
|
<h2><a name="SI8.1" id="SI8.1">8.1 Example 1</a></h2>
|
|
|
|
<p>With the grammar illustrated below, the following
|
|
utterance</p>
|
|
<pre class="sample">
|
|
"I would like a coca cola and three large pizzas with pepperoni and mushrooms."
|
|
</pre>
|
|
|
|
<p>would create the following Rule Variable on the rule
|
|
<code>order</code>:</p>
|
|
|
|
<pre class="sample">
|
|
{
|
|
drink: {
|
|
liquid:"coke",
|
|
drinksize:"medium"},
|
|
pizza: {
|
|
number: "3",
|
|
pizzasize: "large",
|
|
topping: [ "pepperoni", "mushrooms" ]
|
|
}
|
|
}
|
|
</pre>
|
|
|
|
<h5 class="qualif">XML Form</h5>
|
|
<pre class="xml">
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|
|
|
<!DOCTYPE grammar PUBLIC "-//W3C//DTD GRAMMAR 1.0//EN"
|
|
"http://www.w3.org/TR/speech-grammar/grammar.dtd">
|
|
<grammar xmlns="http://www.w3.org/2001/06/grammar" xml:lang="en"
|
|
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
|
|
xsi:schemaLocation="http://www.w3.org/2001/06/grammar
|
|
http://www.w3.org/TR/speech-grammar/grammar.xsd"
|
|
version="1.0" mode="voice" tag-format="semantics/1.0" root="order">
|
|
<rule id="order">
|
|
I would like a
|
|
<ruleref uri="#drink"/>
|
|
<tag>out.drink = new Object(); out.drink.liquid=rules.drink.type;
|
|
out.drink.drinksize=rules.drink.drinksize;</tag>
|
|
and
|
|
<ruleref uri="#pizza"/>
|
|
|
|
<tag>out.pizza=rules.pizza;</tag>
|
|
</rule>
|
|
<rule id="kindofdrink">
|
|
<one-of>
|
|
<item>coke</item>
|
|
|
|
<item>pepsi</item>
|
|
<item>coca cola<tag>out="coke";</tag></item>
|
|
</one-of>
|
|
</rule>
|
|
|
|
<rule id="foodsize">
|
|
<tag>out="medium";</tag> <!-- "medium" is default if nothing said -->
|
|
<item repeat="0-1">
|
|
<one-of>
|
|
<item>small<tag>out="small";</tag></item>
|
|
|
|
<item>medium</item>
|
|
<item>large<tag>out="large";</tag></item>
|
|
<item>regular<tag>out="medium";</tag></item>
|
|
|
|
</one-of>
|
|
</item>
|
|
</rule>
|
|
|
|
<!-- Construct Array of toppings, return Array -->
|
|
<rule id="tops">
|
|
<tag>out=new Array;</tag>
|
|
|
|
<ruleref uri="#top"/>
|
|
<tag>out.push(rules.top);</tag>
|
|
<item repeat="1-">
|
|
and
|
|
<ruleref uri="#top"/>
|
|
<tag>out.push(rules.top);</tag>
|
|
|
|
</item>
|
|
</rule>
|
|
<rule id="top">
|
|
<one-of>
|
|
<item>anchovies</item>
|
|
|
|
<item>pepperoni</item>
|
|
<item>mushroom<tag>out="mushrooms";</tag></item>
|
|
<item>mushrooms</item>
|
|
|
|
</one-of>
|
|
</rule>
|
|
|
|
<!-- Two properties (drinksize, type) on left hand side Rule Variable -->
|
|
<rule id="drink">
|
|
<ruleref uri="#foodsize"/>
|
|
<ruleref uri="#kindofdrink"/>
|
|
|
|
<tag>out.drinksize=rules.foodsize; out.type=rules.kindofdrink;</tag>
|
|
</rule>
|
|
|
|
<!-- Three properties on rules.pizza -->
|
|
<rule id="pizza">
|
|
<ruleref uri="#number"/>
|
|
|
|
<ruleref uri="#foodsize"/>
|
|
<tag>out.pizzasize=rules.foodsize; out.number=rules.number;</tag>
|
|
pizzas with
|
|
<ruleref uri="#tops"/>
|
|
<tag>out.topping=rules.tops;</tag>
|
|
|
|
</rule>
|
|
<rule id="number">
|
|
<one-of>
|
|
<item>
|
|
<tag>out=1;</tag>
|
|
|
|
<one-of>
|
|
<item>a</item>
|
|
<item>one</item>
|
|
</one-of>
|
|
</item>
|
|
|
|
<item>two<tag>out=2;</tag></item>
|
|
<item>three<tag>out=3;</tag></item>
|
|
</one-of>
|
|
|
|
</rule>
|
|
</grammar>
|
|
</pre>
|
|
|
|
<h5 class="qualif">ABNF Form</h5>
|
|
<pre class="abnf">
|
|
#ABNF 1.0 UTF-8;
|
|
language en;
|
|
mode voice;
|
|
tag-format <semantics/1.0>;
|
|
root $order;
|
|
$order = I would like a $drink {out.drink = new Object();
|
|
out.drink.liquid = rules.drink.type;
|
|
out.drink.drinksize = rules.drink.drinksize;}
|
|
and $pizza {out.pizza=rules.pizza;};
|
|
$kindofdrink = coke | pepsi | "coca cola"{out="coke";};
|
|
|
|
// "medium" is default if nothing said
|
|
$foodsize = {out="medium";}
|
|
[small {out="small";} | medium |
|
|
large {out="large";}| regular {out="medium";}];
|
|
|
|
// Construct Array of toppings, return Array
|
|
$tops = {out=new Array;} $top {out.push(rules.top);}
|
|
(and $top {out.push(rules.top);})<1->;
|
|
$top = anchovies | pepperoni | mushroom{out="mushrooms";} | mushrooms;
|
|
|
|
// Two properties (drinksize, type) on left hand side Rule Variable
|
|
$drink = $foodsize $kindofdrink
|
|
{out.drinksize=rules.foodsize; out.type=rules.kindofdrink; };
|
|
|
|
// Three properties on rules.pizza's Rule Variable
|
|
$pizza = $number $foodsize
|
|
{out.pizzasize=rules.foodsize; out.number=rules.number;} pizzas
|
|
with $tops {out.topping=rules.tops;};
|
|
$number = (a | one){out="1";} | two{out="2";} | three{out="3";};
|
|
|
|
|
|
</pre>
|
|
|
|
<h2><a name="SI8.2" id="SI8.2">8.2 Example 2</a></h2>
|
|
|
|
<p>The following grammar demonstrates the use of Semantic
|
|
Interpretation for computation within a grammar.</p>
|
|
|
|
<p>This simple number grammar accepts as input whole numbers
|
|
between 0 and 99,999 inclusive. It demonstrates how rule
|
|
references may be reused multiple times and the returned SI
|
|
information processed differently each time. The grammar also
|
|
shows how the Rule Variable may be given a default value (0 in
|
|
this case) and also used as an intermediate variable during
|
|
computation (essentially incrementing the running total stored in
|
|
the Rule Variable). In this example, the Rule Variable type is
|
|
changed from an Object to a Number but an alternative strategy
|
|
might just as easily store the number as a property of the Rule
|
|
Variable object.</p>
|
|
|
|
<h5 class="qualif">XML Form</h5>
|
|
|
|
<pre class="xml">
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|
<!DOCTYPE grammar PUBLIC "-//W3C//DTD GRAMMAR 1.0//EN"
|
|
"http://www.w3.org/TR/speech-grammar/grammar.dtd">
|
|
<grammar xmlns="http://www.w3.org/2001/06/grammar" xml:lang="en"
|
|
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
|
|
xsi:schemaLocation="http://www.w3.org/2001/06/grammar
|
|
http://www.w3.org/TR/speech-grammar/grammar.xsd"
|
|
version="1.0" mode="voice" tag-format="semantics/1.0" root="main">
|
|
<rule id="main">
|
|
<one-of>
|
|
<item>
|
|
|
|
<ruleref uri="#sub_hundred_thousand"/>
|
|
<tag>out = rules.sub_hundred_thousand;</tag>
|
|
</item>
|
|
<item>
|
|
<ruleref uri="#sub_thousand"/>
|
|
|
|
<tag>out = rules.sub_thousand;</tag>
|
|
</item>
|
|
<item>
|
|
<ruleref uri="#sub_hundred"/>
|
|
<tag>out = rules.sub_hundred;</tag>
|
|
|
|
</item>
|
|
</one-of>
|
|
</rule>
|
|
<rule id="sub_hundred_thousand">
|
|
<ruleref uri="#sub_hundred"/>
|
|
<tag>out = (1000 * rules.sub_hundred)</tag>
|
|
|
|
thousand
|
|
<item repeat="0-1">
|
|
<item repeat="0-1">and</item>
|
|
<ruleref uri="#sub_thousand"/><tag>out += rules.sub_thousand;</tag>
|
|
</item>
|
|
|
|
</rule>
|
|
<rule id="sub_thousand">
|
|
<ruleref uri="#sub_hundred"/>
|
|
<tag>out = (100 * rules.sub_hundred);</tag>
|
|
hundred
|
|
<item repeat="0-1">
|
|
|
|
<item repeat="0-1">and</item>
|
|
<ruleref uri="#sub_hundred"/><tag>out += rules.sub_hundred;</tag>
|
|
</item>
|
|
</rule>
|
|
|
|
<rule id="sub_hundred">
|
|
<tag>out = 0;</tag>
|
|
<one-of>
|
|
<item>zero</item>
|
|
<item><ruleref uri="#teens"/><tag>out += rules.teens;</tag></item>
|
|
|
|
<item>
|
|
<ruleref uri="#tens"/><tag>out += rules.tens;</tag>
|
|
<item repeat="0-1">
|
|
<ruleref uri="#digit"/>
|
|
<tag>out += rules.digit;</tag>
|
|
|
|
</item>
|
|
</item>
|
|
<item><ruleref uri="#digit"/><tag>out += rules.digit;</tag></item>
|
|
</one-of>
|
|
|
|
</rule>
|
|
<rule id="tens">
|
|
<one-of>
|
|
<item>twenty<tag>out = 20;</tag></item>
|
|
|
|
<item>thirty<tag>out = 30;</tag></item>
|
|
<item>forty<tag>out = 40;</tag></item>
|
|
<item>fifty<tag>out = 50;</tag></item>
|
|
|
|
<item>sixty<tag>out = 60;</tag></item>
|
|
<item>seventy<tag>out = 70;</tag></item>
|
|
<item>eighty<tag>out = 80;</tag></item>
|
|
|
|
<item>ninety<tag>out = 90;</tag></item>
|
|
</one-of>
|
|
</rule>
|
|
<rule id="teens">
|
|
|
|
<one-of>
|
|
<item>ten<tag>out = 10;</tag></item>
|
|
<item>eleven<tag>out = 11;</tag></item>
|
|
|
|
<item>twelve<tag>out = 12;</tag></item>
|
|
<item>thirteen<tag>out = 13;</tag></item>
|
|
<item>fourteen<tag>out = 14;</tag></item>
|
|
|
|
<item>fifteen<tag>out = 15;</tag></item>
|
|
<item>sixteen<tag>out = 16;</tag></item>
|
|
<item>seventeen<tag>out = 17;</tag></item>
|
|
|
|
<item>eighteen<tag>out = 18;</tag></item>
|
|
<item>nineteen<tag>out = 19;</tag></item>
|
|
</one-of>
|
|
|
|
</rule>
|
|
<rule id="digit">
|
|
<one-of>
|
|
<item>one<tag>out = 1;</tag></item>
|
|
|
|
<item>two<tag>out = 2;</tag></item>
|
|
<item>three<tag>out = 3;</tag></item>
|
|
<item>four<tag>out = 4;</tag></item>
|
|
|
|
<item>five<tag>out = 5;</tag></item>
|
|
<item>six<tag>out = 6;</tag></item>
|
|
<item>seven<tag>out = 7;</tag></item>
|
|
|
|
<item>eight<tag>out = 8;</tag></item>
|
|
<item>nine<tag>out = 9;</tag></item>
|
|
</one-of>
|
|
|
|
</rule>
|
|
</grammar>
|
|
</pre>
|
|
|
|
<h5 class="qualif">ABNF Form</h5>
|
|
<pre class="abnf">
|
|
#ABNF 1.0 UTF-8;
|
|
language en;
|
|
mode voice;
|
|
tag-format <semantics/1.0>;
|
|
root $main;
|
|
$main = $sub_hundred_thousand { out = rules.sub_hundred_thousand; } |
|
|
$sub_thousand { out = rules.sub_thousand; } |
|
|
$sub_hundred { out = rules.sub_hundred; };
|
|
$sub_hundred_thousand = $sub_hundred { out = (1000 * rules.sub_hundred); }
|
|
thousand
|
|
[ [and] $sub_thousand { out += rules.sub_thousand; } ];
|
|
$sub_thousand = $sub_hundred { out = (100 * rules.sub_hundred); } hundred
|
|
[ [and] $sub_hundred { out += rules.sub_hundred; } ];
|
|
$sub_hundred = { out = 0; } (zero | $teens { out += rules.teens; } |
|
|
$tens { out += rules.tens; }
|
|
[ $digit { out += rules.digit; } ] |
|
|
$digit { out += rules.digit; });
|
|
$tens = twenty { out = 20; } | thirty { out = 30; } | forty { out = 40; } |
|
|
fifty { out = 50; } | sixty { out = 60; } | seventy { out = 70; } |
|
|
eighty { out = 80; } | ninety { out = 90; };
|
|
$teens = ten { out = 10; } | eleven { out = 11; } | twelve { out = 12; } |
|
|
thirteen { out = 13; } | fourteen { out = 14; } |
|
|
fifteen { out = 15; } | sixteen { out = 16; } |
|
|
seventeen { out = 17; } | eighteen { out = 18; } |
|
|
nineteen { out = 19; };
|
|
$digit = one { out = 1; } | two { out = 2; } | three { out = 3; } |
|
|
four { out = 4; } | five { out = 5; } | six { out = 6; } |
|
|
seven { out = 7; } | eight { out = 8; } | nine { out = 9; };
|
|
</pre>
|
|
|
|
<h1><a id="SIA" name="SIA">A Conformance</a></h1>
|
|
|
|
<p><strong>This section is normative.</strong></p>
|
|
|
|
<h2 id="L668"><a name="SIA.1" id="SIA.1">A.1 Conforming Semantic
|
|
Interpretation Tags</a></h2>
|
|
|
|
<p>A Semantic Interpretation Tag (SI Tag) is a Conforming SI Tag
|
|
if its content matches the syntax as defined in the normative
|
|
sections in this document.</p>
|
|
|
|
<p>There is no normative restriction on the size of a SI Tag.</p>
|
|
|
|
<h2 id="L669"><a name="SIA.2" id="SIA.2">A.2 Conforming Semantic
|
|
Interpretation Grammars</a></h2>
|
|
|
|
<p>A Conforming Semantic Interpretation Grammar is a stand-alone
|
|
ABNF or XML Grammar Document or an XML Grammar Fragment
|
|
where:</p>
|
|
|
|
<ol>
|
|
<li>The document or fragment is a conforming ABNF or XML
|
|
document or XML fragment as defined by the conformance
|
|
requirements in [<a href="#refSRGS">SRGS</a>].</li>
|
|
|
|
<li>The tag-format [<a href="#refSRGS">SRGS</a>] for the
|
|
grammar fragment or document is <code>semantics/1.0</code> or
|
|
<code>semantics/1.0-literals</code>.</li>
|
|
|
|
<li>Every tag in the grammar document or fragment is a
|
|
Conforming SI Tag.</li>
|
|
</ol>
|
|
|
|
<p>A grammar that contains tags in a format other than specified
|
|
by this document or its successors must have a tag format
|
|
declaration with a value that is not beginning with the string
|
|
<code>semantics/x.y</code> (where <code>x</code> and
|
|
<code>y</code> are digits) (see Speech Recognition Grammar
|
|
Specification 4.8 Tag Format Declaration [<a href="#refSRGS">SRGS</a>]).</p>
|
|
|
|
<h2 id="L709"><a name="SIA.3" id="SIA.3">A.3 Conforming Semantic
|
|
Interpretation Processors</a></h2>
|
|
|
|
<p>A Semantic Interpretation Processor is a program that can
|
|
parse and process Conforming SI Tags to produce semantic results.
|
|
Semantic Interpretation Processors are executed in a hosting
|
|
environment (e.g. a grammar processor).</p>
|
|
|
|
<p>A Conforming Semantic Interpretation Processor:</p>
|
|
|
|
<ol>
|
|
<li>Must be capable of accepting and executing Conforming SI
|
|
Tags.</li>
|
|
|
|
<li>Should inform the hosting environment at the time it
|
|
evaluates a Conforming SI Tag that causes a runtime error.</li>
|
|
|
|
<li>Must inform the hosting environment when it encounters a
|
|
non-conforming Semantic Interpretation Tag. A processor is free
|
|
to inform the hosting environment of such a non-conforming tag
|
|
any time between loading the non-conforming SI Tag and
|
|
evaluating the offending language construct in the
|
|
non-conforming SI Tag. There is no requirement for a processor
|
|
to continue processing after encountering a non-conforming
|
|
tag.</li>
|
|
</ol>
|
|
|
|
<h2 id="L767"><a name="SIA.4" id="SIA.4">A.4 Conforming Semantic
|
|
Interpretation Grammar Processors</a></h2>
|
|
|
|
<p>A Semantic Interpretation Grammar Processor is a system that
|
|
can parse and process Conforming Semantic Interpretation
|
|
Grammars. Specifically, a Semantic Interpretation Grammar
|
|
Processor is a conforming processor if:</p>
|
|
|
|
<ol>
|
|
|
|
<li>It is a conforming ABNF or XML Grammar Processor as defined
|
|
in the Speech Recognition Grammar Specification [<a href="#refSRGS">SRGS</a>].</li>
|
|
|
|
<li>It is a conforming Semantic Interpretation Processor.</li>
|
|
</ol>
|
|
|
|
<h2><a name="SIA.5" id="SIA.5">A.5 Conformance
|
|
Statements</a></h2>
|
|
|
|
<h3><a name="SIA.5.1" id="SIA.5.1">A.5.1 Conformance Statement
|
|
for Conforming Documents</a></h3>
|
|
|
|
<p>Anyone wishing to state conformance of a Grammar Fragment or
|
|
Grammar Document with SI Tags (document) to this specification
|
|
should use the following wording:</p>This document conforms to
|
|
W3C's "Semantic Interpretation for Speech Recognition", available
|
|
at
|
|
http://www.w3.org/TR/semantic-interpretation/.
|
|
|
|
<h3><a name="SIA.5.2" id="SIA.5.2">A.5.2 Conformance Statement
|
|
for Conforming Processors</a></h3>
|
|
|
|
<p>Anyone wishing to state conformance of a processor to this
|
|
specification should use the following wording:</p>
|
|
|
|
<p>[PROCESSOR] is a Conforming [ (1) ABNF, (2) XML, (3) ABNF and
|
|
XML ] Semantic Interpretation Grammar Processor according to
|
|
W3C's "Semantic Interpretation for Speech Recognition", available
|
|
at
|
|
http://www.w3.org/TR/semantic-interpretation/
|
|
[with support for XML Transformation].</p>
|
|
|
|
<p>Make the appropriate substitutions:</p>
|
|
|
|
<ul>
|
|
<li>[PROCESSOR]: Appropriate reference to the processor, such
|
|
as name, version, and vendor.</li>
|
|
|
|
<li>[(1) ABNF, (2) XML, (3) ABNF and XML]: Choose one of the
|
|
three options as applicable.</li>
|
|
|
|
<li>[with support for XML Transformation]: optional phrase if
|
|
the processor fully implements the optional XML Transformation
|
|
described in section <a href="#SI7">7</a>.</li>
|
|
|
|
</ul>
|
|
|
|
<h1><a name="SIB" id="SIB">B Glossary</a></h1>
|
|
|
|
<dl class="glossary">
|
|
<dt>ABNF</dt>
|
|
|
|
<dd>Augmented BNF, a syntax used for specifying Speech
|
|
Recognition Grammars (defined in [<a href="#refSRGS">SRGS</a>]).</dd>
|
|
|
|
<dt>ASR (Automatic Speech Recognition)</dt>
|
|
|
|
<dd>The process of using an automatic computation algorithm to
|
|
analyze spoken utterances to determine what words and phrases
|
|
were present.</dd>
|
|
|
|
<dt>ECMA</dt>
|
|
|
|
<dd>Ecma International (see [<a href="#refECMA">ECMA</a>]) is
|
|
an industry association founded in 1961, dedicated to the
|
|
standardization of information and communication systems.
|
|
ECMAScript is a standard published by ECMA</dd>
|
|
|
|
<dt>ECMA Compact Profile</dt>
|
|
|
|
<dd>ECMAScript Compact Profile (see [<a href="#refECMA327">ECMA-327</a>]) is a subset of ECMAScript 3rd
|
|
Edition tailored to resource-constrained devices such as
|
|
battery-powered embedded devices.</dd>
|
|
|
|
<dt>ECMAScript</dt>
|
|
|
|
<dd>See Script.</dd>
|
|
|
|
<dt>Grammar</dt>
|
|
|
|
<dd>Shorthand for Speech Recognition Grammar.</dd>
|
|
|
|
<dt>Grammar Document</dt>
|
|
|
|
<dd>An XML or ABNF Document Grammar Document as defined in
|
|
sections 5.2 and 5.5 of [<a href="#refSRGS">SRGS</a>].</dd>
|
|
|
|
<dt>Grammar Fragment</dt>
|
|
|
|
<dd>An XML Fragment as defined in section 5.1 of [<a href="#refSRGS">SRGS</a>].</dd>
|
|
|
|
<dt>Hosting environment</dt>
|
|
|
|
<dd>The Grammar processor or VoiceXML processor or other
|
|
computer program that contains a processor for Semantic
|
|
Interpretation</dd>
|
|
|
|
<dt>Logical Parse Structure</dt>
|
|
|
|
<dd>A representation of a parse as a hierarchical structure.
|
|
See section <a href="#SI6.1">6.1</a></dd>
|
|
|
|
<dt>Parse</dt>
|
|
|
|
<dd>Noun (1): A structured representation of the (possible)
|
|
application of Grammar Rules to the sequence of Tokens in an
|
|
utterance. See section <a href="#SI6">6</a> for definition of
|
|
Parse structure and Parse list in this specification.</dd>
|
|
|
|
<dd>Noun (2): A structured representation of the contents of a
|
|
document by analyzing the stream of characters against the
|
|
defined model for the document.</dd>
|
|
|
|
<dd>Verb: The process of creating a Parse.</dd>
|
|
|
|
<dt>Parse List (Flat Parse List)</dt>
|
|
|
|
<dd>A representation of a parse as a linear sequence of applied
|
|
rules. See section <a href="#SI6.2">6.2</a></dd>
|
|
|
|
<dt>Rule (Grammar Rule)</dt>
|
|
|
|
<dd>A Rule Definition describes the composition of a possible
|
|
utterance in terms of other Rule Definitions and Tokens. See
|
|
details in section 3.1 of [<a href="#refSRGS">SRGS</a>].</dd>
|
|
|
|
<dt>Script (ECMAScript)</dt>
|
|
|
|
<dd>A computer program listing the instructions to be executed.
|
|
In SI, scripts are written in the ECMAScript programming
|
|
language. (See [<a href="#refECMA262">ECMA-262</a>])</dd>
|
|
|
|
<dt>Semantic Interpretation</dt>
|
|
|
|
<dd>A process to produce a Semantic Result representing the
|
|
meaning of a natural language utterance.</dd>
|
|
|
|
<dt>Semantic Result or Semantic Value</dt>
|
|
|
|
<dd>A computer processable representation of the information
|
|
(the meaning, or "semantics") contained in a user input. In the
|
|
context of this specification the user input is a natural
|
|
language utterances. A Semantic Result is used here in the
|
|
relatively narrow sense of representing the information that is
|
|
<i>relevant</i> to the application that is intended to process
|
|
it, typically using ad-hoc conventions for the representation.
|
|
See section <a href="#SI1.1">1.1</a>.</dd>
|
|
|
|
<dt>Speech Recognizer</dt>
|
|
|
|
<dd>A program or device that performs Automatic Speech
|
|
Recognition</dd>
|
|
|
|
<dt>Speech Recognition Grammar</dt>
|
|
|
|
<dd>A description of the candidate words and phrases for use by
|
|
a Speech Recognizer. Speech Recognition Grammars for use with
|
|
this specification are defined in [<a href="#refSRGS">SRGS</a>], a standardized format for context-free
|
|
grammars.</dd>
|
|
|
|
<dt>SRGS</dt>
|
|
|
|
<dd>Speech Recognition Grammar Specification for the W3C Speech
|
|
Interface Framework. See [<a href="#refSRGS">SRGS</a>]</dd>
|
|
|
|
<dt>String Literal</dt>
|
|
|
|
<dd>A sequence of zero or more characters. String Literals in
|
|
this specification are defined in section <a href="#SI3.2.3">3.2.3</a>.</dd>
|
|
|
|
<dt>Token</dt>
|
|
|
|
<dd>A token (a.k.a. a terminal symbol) is the part of a Grammar
|
|
that defines words or other entities that may be spoken (see
|
|
section 2 of [<a href="#refSRGS">SRGS</a>]).</dd>
|
|
|
|
<dt>VoiceXML</dt>
|
|
|
|
<dd>VoiceXML is markup language designed for creating audio
|
|
dialogs that feature synthesized speech, digitized audio,
|
|
recognition of spoken and DTMF key input, recording of spoken
|
|
input, telephony, and mixed initiative conversations. VoiceXML
|
|
is part of the W3C Speech Interface Framework. See [<a href="#refVoiceXML">VOICEXML20</a>].</dd>
|
|
|
|
<dt>XML</dt>
|
|
|
|
<dd>A simple dialect of SGML intended to enable generic SGML to
|
|
be served, received, and processed on the Web. See <a href="http://www.w3.org/2003/glossary/keyword/All/?keywords=XML">W3C
|
|
Glossary for XML</a>.</dd>
|
|
</dl>
|
|
|
|
<h1><a name="SIC" id="SIC">C Normative References</a></h1>
|
|
|
|
<dl>
|
|
<dt><a name="refECMA262" id="refECMA262">ECMA-262</a></dt>
|
|
|
|
<dd><cite><a href="http://www.ecma-international.org/publications/standards/Ecma-262.htm">
|
|
|
|
Standard ECMA-262</a></cite>, 3<sup>rd</sup> Edition, December
|
|
1999,
|
|
http://www.ecma-international.org/publications/standards/Ecma-262.htm
|
|
.</dd>
|
|
|
|
<dt><a name="refECMA327" id="refECMA327">ECMA-327</a></dt>
|
|
|
|
<dd><cite><a href="http://www.ecma-international.org/publications/standards/Ecma-327.htm">
|
|
Standard ECMA-327</a></cite>, 3<sup>rd</sup> Edition Compact
|
|
Profile, June 2001,
|
|
http://www.ecma-international.org/publications/standards/Ecma-327.htm
|
|
.</dd>
|
|
|
|
<dt><a name="refRFC2119" id="refRFC2119">RFC2119</a></dt>
|
|
|
|
<dd><cite><a href="http://www.ietf.org/rfc/rfc2119.txt">Key
|
|
words for use in RFCs to Indicate Requirement Levels</a></cite>
|
|
|
|
, IETF RFC 2119, March 1997.
|
|
http://www.ietf.org/rfc/rfc2119.txt .</dd>
|
|
|
|
<dt><a name="refSRGS" id="refSRGS">SRGS</a></dt>
|
|
|
|
<dd><cite><a href="http://www.w3.org/TR/2004/REC-speech-grammar-20040316/">Speech
|
|
Recognition Grammar Specification Version 1.0</a></cite> , A.
|
|
Hunt, S. McGlashan, Editors, W3C Recommendation, 16 March 2004,
|
|
http://www.w3.org/TR/2004/REC-speech-grammar-20040316/ .
|
|
<a href="http://www.w3.org/TR/speech-grammar/" title="Latest version of Speech Recognition Grammar Specification Version 1.0">
|
|
|
|
Latest version</a> available at
|
|
http://www.w3.org/TR/speech-grammar/ .</dd>
|
|
|
|
<dt><a name="refVoiceXML" id="refVoiceXML">VOICEXML20</a></dt>
|
|
|
|
<dd><cite><a href="http://www.w3.org/TR/2004/REC-voicexml20-20040316/">Voice
|
|
Extensible Markup Language (VoiceXML) Version 2.0</a></cite>,
|
|
J. Ferrans, B. Lucas, K. G. Rehor, B. Porter, A. Hunt, S.
|
|
McGlashan, S. Tryphonas, D. C. Burnett, J. Carter, P.
|
|
Danielsen, Editors, W3C Recommendation, 16 March 2004,
|
|
http://www.w3.org/TR/2004/REC-voicexml20-20040316/ . <a href="http://www.w3.org/TR/voicexml20/" title="Latest version of Voice Extensible Markup Language (VoiceXML) Version 2.0">
|
|
Latest version</a> available at
|
|
http://www.w3.org/TR/voicexml20/ .</dd>
|
|
|
|
|
|
<dt><a name="refXML" id="refXML">XML</a></dt>
|
|
|
|
<dd><cite><a href="http://www.w3.org/TR/2006/REC-xml-20060816">Extensible Markup Language (XML) 1.0
|
|
(Fourth Edition)</a></cite>, T. Bray, J. Paoli, C. M. Sperberg-McQueen, E. Maler, F. Yergeau, Editors,
|
|
W3C Recommendation, 16 August 2006,
|
|
http://www.w3.org/TR/2006/REC-xml-20060816 . <a href="http://www.w3.org/TR/xml" title="XML">Latest version</a> available at
|
|
http://www.w3.org/TR/xml .</dd>
|
|
|
|
<dt><a name="refXMLNames" id="refXMLNames">XML-NAMES</a></dt>
|
|
|
|
<dd><cite><a href="http://www.w3.org/TR/2006/REC-xml-names-20060816/">Namespaces
|
|
in XML 1.0 (Second Edition)</a></cite>, T. Bray, D. Hollander, A. Layman, R. Tobin, Editors,
|
|
W3C Recommendation, 16 August 2006,
|
|
http://www.w3.org/TR/2006/REC-xml-names-20060816/ . <a href="http://www.w3.org/TR/xml-names/" title="Namespaces in XML">Latest version</a> available at
|
|
http://www.w3.org/TR/xml-names/ .</dd>
|
|
|
|
</dl>
|
|
|
|
<h1><a name="SID" id="SID">D Informative References</a></h1>
|
|
|
|
<dl>
|
|
<dt><a name="refECMA" id="refECMA">ECMA</a></dt>
|
|
|
|
<dd><cite><a href="http://www.ecma-international.org/">ECMA
|
|
International - Standardizing Information and Communication
|
|
Systems</a></cite>, http://www.ecma-international.org/ .</dd>
|
|
|
|
<dt><a name="refEMMA" id="refEMMA">EMMA</a></dt>
|
|
|
|
<dd><cite><a href="http://www.w3.org/TR/2005/WD-emma-20050916/">EMMA: Extensible
|
|
MultiModal Annotation Markup Language</a></cite>, M. Johnston,
|
|
W. Chou, D. A. Dahl, G. McCobb, D. Raggett, Editors, W3C
|
|
Working Draft (work in progress), 16 September 2005,
|
|
http://www.w3.org/TR/2005/WD-emma-20050916/ . <a href="http://www.w3.org/TR/emma/" title="Latest version of EMMA: Extensible MultiModal Annotation Markup Language">
|
|
|
|
Latest version</a> available at http://www.w3.org/TR/emma/
|
|
.</dd>
|
|
|
|
<dt><a name="refMMI" id="refMMI">MMI</a></dt>
|
|
|
|
<dd><cite><a href="http://www.w3.org/2002/mmi/">W3C Multimodal
|
|
Interaction Activity</a></cite>, http://www.w3.org/2002/mmi/
|
|
.</dd>
|
|
|
|
<dt><a name="refMMI-Arch" id="refMMI-Arch">MMI-FRAMEWORK</a></dt>
|
|
|
|
<dd><cite><a href="http://www.w3.org/TR/2003/NOTE-mmi-framework-20030506/">W3C
|
|
|
|
Multimodal Interaction Framework</a></cite>, J. A. Larson, T. V. Raman, D.
|
|
Raggett, Editors, W3C Working Group Note, 6 May 2003,
|
|
http://www.w3.org/TR/2003/NOTE-mmi-framework-20030506/ .
|
|
<a href="http://www.w3.org/TR/mmi-framework/" title="Latest version of W3C Multimodal Interaction Framework">Latest
|
|
version</a> available at http://www.w3.org/TR/mmi-framework/
|
|
.</dd>
|
|
|
|
<dt><a name="refNgrams" id="refNgrams">N-GRAMS</a></dt>
|
|
|
|
<dd><cite><a href="http://www.w3.org/TR/2001/WD-ngram-spec-20010103/">Stochastic
|
|
Language Models (N-Gram) Specification</a></cite>, N. K. Brown,
|
|
A. Kellner, D. Raggett, Editors. W3C Working Draft (work in
|
|
progress), 3 January 2001,
|
|
http://www.w3.org/TR/2001/WD-ngram-spec-20010103/ . <a href="http://www.w3.org/TR/ngram-spec/" title="Stochastic Language Models (N-Gram) Specification">Latest
|
|
version</a> available at http://www.w3.org/TR/ngram-spec/
|
|
.</dd>
|
|
|
|
<dt><a name="refVoice" id="refVoice">VBWG</a></dt>
|
|
|
|
<dd><cite><a href="http://www.w3.org/Voice/">W3C Voice Browser
|
|
Activity</a></cite>, http://www.w3.org/Voice/ .</dd>
|
|
|
|
<dt><a name="refXMLSchema" id="refXMLSchema">XML-SCHEMA</a></dt>
|
|
|
|
<dd><cite><a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/">XML Schema Part 1:
|
|
Structures Second Edition</a></cite>, H. S. Thompson,
|
|
D. Beech, M. Maloney, N. Mendelsohn, Editors. W3C Recommendation, 28 October 2004,
|
|
http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/ . <a href="http://www.w3.org/TR/xmlschema-1/"
|
|
title="XML Schema Part 1: Structures Second Edition">Latest
|
|
version</a> available at http://www.w3.org/TR/xmlschema-1/
|
|
.</dd>
|
|
|
|
</dl>
|
|
|
|
<h1 id="Acknowledg"><a name="SIE" id="SIE">E
|
|
Acknowledgments</a></h1>
|
|
|
|
<p>This document was written with the participation of members of
|
|
the W3C Voice Browser Working Group [<a href="#refVoice">VBWG</a>]. The following have significantly
|
|
contributed to writing this specification:</p>
|
|
|
|
<ul>
|
|
|
|
<li>Paolo Baggia, Loquendo</li>
|
|
|
|
<li>Dominique Boucher, Nu Echo</li>
|
|
|
|
<li>Dan Burnett, Nuance Communications</li>
|
|
|
|
<li>Dave Burke, Voxpilot</li>
|
|
|
|
<li>Jerry Carter, Nuance Communications</li>
|
|
|
|
<li>Sasha Caskey, IBM</li>
|
|
|
|
<li>Andrew Hunt, Nuance Communications</li>
|
|
|
|
<li>Stefan Krause, Nuance Communications</li>
|
|
|
|
<li>Jeff Kusnitz, IBM</li>
|
|
|
|
<li>Bruce Lucas, IBM</li>
|
|
|
|
<li>Mitsuru Oshima, General Magic</li>
|
|
|
|
<li>Stephen Potter, Microsoft</li>
|
|
|
|
<li>Jan Verhasselt, Nuance Communications</li>
|
|
|
|
<li>Dave Wood, Microsoft</li>
|
|
|
|
</ul>
|
|
|
|
</body>
|
|
</html>
|
|
|
|
|
|
|
|
|
|
|