index.html 121 KB

Raw Blame History Permalink

<?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>&lt;tag&gt;</code> element:</p>
  <pre class="sample">
&lt;tag&gt; <i>tag-content</i> &lt;/tag&gt;
</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">
&lt;grammar version="1.0" xmlns="http://www.w3.org/2001/06/grammar"
         xml:lang="en-US" tag-format="semantics/1.0-literals" root="answer"&gt;
   &lt;rule id="answer" scope="public"&gt;

      &lt;one-of&gt;
         &lt;item&gt;&lt;ruleref uri="#yes"/&gt;&lt;/item&gt;
         &lt;item&gt;&lt;ruleref uri="#no"/&gt;&lt;/item&gt;
      &lt;/one-of&gt;
   &lt;/rule&gt;

   &lt;rule id="yes"&gt;
      &lt;one-of&gt;
         &lt;item&gt;yes&lt;/item&gt;
         &lt;item&gt;yeah&lt;tag&gt;yes&lt;/tag&gt;&lt;/item&gt;

         &lt;item&gt;&lt;token&gt;you bet&lt;/token&gt;&lt;tag&gt;yes&lt;/tag&gt;&lt;/item&gt;
         &lt;item xml:lang="fr-CA"&gt;oui&lt;tag&gt;yes&lt;/tag&gt;&lt;/item&gt;

      &lt;/one-of&gt;
   &lt;/rule&gt;
   &lt;rule id="no"&gt;
      &lt;one-of&gt;
         &lt;item&gt;no&lt;/item&gt;

         &lt;item&gt;nope&lt;/item&gt;
         &lt;item&gt;no way&lt;/item&gt;
      &lt;/one-of&gt;
      &lt;tag&gt;no&lt;/tag&gt;

   &lt;/rule&gt;
&lt;/grammar&gt;
</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">
&lt;grammar version="1.0" xmlns="http://www.w3.org/2001/06/grammar"
         xml:lang="en-US" tag-format="semantics/1.0" root="answer"&gt;
   &lt;rule id="answer" scope="public"&gt;

      &lt;one-of&gt;
         &lt;item&gt;&lt;ruleref uri="#yes"/&gt;&lt;/item&gt;
         &lt;item&gt;&lt;ruleref uri="#no"/&gt;&lt;/item&gt;
      &lt;/one-of&gt;
   &lt;/rule&gt;

   &lt;rule id="yes"&gt;
      &lt;one-of&gt;
         &lt;item&gt;yes&lt;/item&gt;
         &lt;item&gt;yeah&lt;tag&gt;out="yes";&lt;/tag&gt;&lt;/item&gt;

         &lt;item&gt;&lt;token&gt;you bet&lt;/token&gt;&lt;tag&gt;out="yes";&lt;/tag&gt;&lt;/item&gt;
         &lt;item xml:lang="fr-CA"&gt;oui&lt;tag&gt;out="yes";&lt;/tag&gt;&lt;/item&gt;

      &lt;/one-of&gt;
   &lt;/rule&gt;
   &lt;rule id="no"&gt;
      &lt;one-of&gt;
         &lt;item&gt;no&lt;/item&gt;

         &lt;item&gt;nope&lt;/item&gt;
         &lt;item&gt;no way&lt;/item&gt;
      &lt;/one-of&gt;
      &lt;tag&gt;out="no";&lt;/tag&gt;

   &lt;/rule&gt;
&lt;/grammar&gt;
</pre>

  <h5>ABNF Form</h5>
  <pre class="abnf">
#ABNF 1.0;
language en-US;
tag-format &lt;semantics/1.0-literals&gt;;
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 &lt;semantics/1.0&gt;;
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>&lt;grammar&gt;</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">
&lt;grammar version="1.0" xmlns="http://www.w3.org/2001/06/grammar"
         xml:lang="en-US" tag-format="semantics/1.0" root="drink"&gt;
   &lt;rule id="drink"&gt;
      &lt;-- Note: rules object always exists in scope --&gt;
      &lt;tag&gt;rules.foodsize="medium";&lt;/tag&gt;
      &lt;item repeat="0-1"&gt;

         &lt;ruleref uri="#foodsize"/&gt;
      &lt;/item&gt;
      &lt;ruleref uri="#kindofdrink"/&gt;
      &lt;tag&gt;out.drinksize=rules.foodsize; out.type=rules.kindofdrink;&lt;/tag&gt;
   &lt;/rule&gt;

   &lt;rule id="foodsize"&gt;
      &lt;one-of&gt;
         &lt;item&gt;small&lt;/item&gt;
         &lt;item&gt;medium&lt;/item&gt;
         &lt;item&gt;large&lt;/item&gt;

      &lt;/one-of&gt;
   &lt;/rule&gt;
   &lt;rule id="kindofdrink"&gt;
      &lt;one-of&gt;
         &lt;item&gt;coke&lt;/item&gt;

         &lt;item&gt;pepsi&lt;/item&gt;
      &lt;/one-of&gt;
   &lt;/rule&gt;
&lt;/grammar&gt;
</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>&lt;tag&gt;</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">

&lt;grammar version="1.0" xmlns="http://www.w3.org/2001/06/grammar"
         xml:lang="en-US" tag-format="semantics/1.0" root="rule"&gt;
   &lt;tag&gt;var x=1;&lt;/tag&gt;
   &lt;tag&gt;var y='abcd';&lt;/tag&gt;
   &lt;rule id="rule"&gt;
      &lt;one-of&gt;

         &lt;item&gt;yes&lt;/item&gt;
         &lt;item&gt;no&lt;/item&gt;
      &lt;/one-of&gt;
   &lt;/rule&gt;
&lt;/grammar&gt;

</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 &lt;semantics/1.0&gt;;
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">
&lt;rule id="drink"&gt;
   &lt;one-of&gt;
      &lt;item&gt;coke&lt;/item&gt;
      &lt;item&gt;pepsi&lt;/item&gt;

      &lt;item&gt;coca cola&lt;/item&gt;
   &lt;/one-of&gt;
&lt;/rule&gt;
</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">
&lt;rule id="drink"&gt;
   &lt;one-of&gt;
      &lt;item&gt;coke&lt;/item&gt;

      &lt;item&gt;pepsi&lt;/item&gt;
      &lt;item&gt;coca cola&lt;tag&gt;coke&lt;/tag&gt;&lt;/item&gt;
   &lt;/one-of&gt;
&lt;/rule&gt;

</pre>

  <p>For the following grammar, the utterance "I want to fly to
  Boston" will return the result "BOS".</p>

  <pre class="xml">
&lt;grammar version="1.0" xmlns="http://www.w3.org/2001/06/grammar"
         xml:lang="en-US" tag-format="semantics/1.0-literals" root="flight"&gt;
   &lt;rule id="flight" scope="public"&gt;
      I want to fly to
      &lt;ruleref uri="#airports"/&gt;

   &lt;/rule&gt;
   &lt;rule id="airports" scope="private"&gt;
      &lt;one-of&gt;
         &lt;item&gt;&lt;ruleref uri="#USairport"/&gt;&lt;/item&gt;
         &lt;item&gt;&lt;ruleref uri="#otherairport"/&gt;&lt;/item&gt;

      &lt;/one-of&gt;
   &lt;/rule&gt;
   &lt;rule id="USairport" scope="private"&gt;
      &lt;one-of&gt;
         &lt;item&gt;Boston&lt;tag&gt;BOS&lt;/tag&gt;&lt;/item&gt;

         &lt;item&gt;New York&lt;tag&gt;JFK&lt;/tag&gt;&lt;/item&gt;
         &lt;item&gt;Chicago&lt;tag&gt;ORD&lt;/tag&gt;&lt;/item&gt;
      &lt;/one-of&gt;

   &lt;/rule&gt;
   &lt;rule id="otherairport" scope="private"&gt;
      &lt;one-of&gt;
         &lt;item&gt;Brussels&lt;tag&gt;BRU&lt;/tag&gt;&lt;/item&gt;

         &lt;item&gt;Paris&lt;tag&gt;CDG&lt;/tag&gt;&lt;/item&gt;
         &lt;item&gt;Rome&lt;tag&gt;FCO&lt;/tag&gt;&lt;/item&gt;
      &lt;/one-of&gt;

   &lt;/rule&gt;
&lt;/grammar&gt;
</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">
&lt;grammar version="1.0" xmlns="http://www.w3.org/2001/06/grammar"
         xml:lang="en-US" tag-format="semantics/1.0-literals" root="flight"&gt;
   &lt;rule id="flight" scope="public"&gt;

      I want to fly from
      &lt;one-of&gt;
         &lt;item&gt;&lt;ruleref uri="#USairport"/&gt;&lt;/item&gt;
         &lt;item&gt;&lt;ruleref uri="#otherairport"/&gt;&lt;/item&gt;
      &lt;/one-of&gt;

      to
      &lt;one-of&gt;
         &lt;item&gt;&lt;ruleref uri="#USairport "/&gt;&lt;/item&gt;
         &lt;item&gt;&lt;ruleref uri="#otherairport"/&gt;&lt;/item&gt;
     &lt;/one-of&gt;

   &lt;/rule&gt;
   &lt;rule id="USairport" scope="private"&gt;
      &lt;one-of&gt;
         &lt;item&gt;Boston&lt;tag&gt;BOS&lt;/tag&gt;&lt;/item&gt;

         &lt;item&gt;New York&lt;tag&gt;JFK&lt;/tag&gt;&lt;/item&gt;
         &lt;item&gt;Chicago&lt;tag&gt;ORD&lt;/tag&gt;&lt;/item&gt;
      &lt;/one-of&gt;

   &lt;/rule&gt;
   &lt;rule id="otherairport" scope="private"&gt;
      &lt;one-of&gt;
         &lt;item&gt;Brussels&lt;tag&gt;BRU&lt;/tag&gt;&lt;/item&gt;

         &lt;item&gt;Paris&lt;tag&gt;CDG&lt;/tag&gt;&lt;/item&gt;
         &lt;item&gt;Rome&lt;tag&gt;FCO&lt;/tag&gt;&lt;/item&gt;
      &lt;/one-of&gt;

   &lt;/rule&gt;
&lt;/grammar&gt;
</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">
&lt;grammar version="1.0" xmlns="http://www.w3.org/2001/06/grammar"
         xml:lang="en-US" tag-format="semantics/1.0" root="flight"&gt;
   &lt;rule id="flight" scope="public"&gt;

      I want to fly from
      &lt;one-of&gt;
         &lt;item&gt;
            &lt;ruleref uri="http://www.example.com/places.grxml"/&gt;
         &lt;/item&gt;
         &lt;item&gt;
            &lt;ruleref uri="http://www.example.com/places.grxml#otherairport"/&gt;

         &lt;/item&gt;
      &lt;/one-of&gt;
      &lt;tag&gt;out.departure = rules.latest();&lt;/tag&gt;
      to
      &lt;one-of&gt;
         &lt;item&gt;

            &lt;ruleref uri="http://www.example.com/places.grxml"/&gt;
         &lt;/item&gt;
         &lt;item&gt;
            &lt;ruleref uri="http://www.example.com/places.grxml#otherairport"/&gt;
         &lt;/item&gt;
      &lt;/one-of&gt;

      &lt;tag&gt;out.arrival = rules.latest();&lt;/tag&gt;
   &lt;/rule&gt;
&lt;/grammar&gt;
</pre>

  <p>Grammar http://www.example.com/places.grxml:</p>
  <pre class="xml">

&lt;grammar version="1.0" xmlns="http://www.w3.org/2001/06/grammar"
         xml:lang="en-US" tag-format="semantics/1.0-literals" root="USairport"&gt;
   &lt;rule id="USairport" scope="public"&gt;
      &lt;one-of&gt;
         &lt;item&gt;Boston&lt;tag&gt;BOS&lt;/tag&gt;&lt;/item&gt;
         &lt;item&gt;New York&lt;tag&gt;JFK&lt;/tag&gt;&lt;/item&gt;

         &lt;item&gt;Chicago&lt;tag&gt;ORD&lt;/tag&gt;&lt;/item&gt;
      &lt;/one-of&gt;
   &lt;/rule&gt;
   &lt;rule id="otherairport" scope="public"&gt;

      &lt;one-of&gt;
         &lt;item&gt;Brussels&lt;tag&gt;BRU&lt;/tag&gt;&lt;/item&gt;
         &lt;item&gt;Paris&lt;tag&gt;CDG&lt;/tag&gt;&lt;/item&gt;

         &lt;item&gt;Rome&lt;tag&gt;FCO&lt;/tag&gt;&lt;/item&gt;
      &lt;/one-of&gt;
   &lt;/rule&gt;
&lt;/grammar&gt;
</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">
&lt;grammar version="1.0" xmlns="http://www.w3.org/2001/06/grammar"
         xml:lang="en-US" tag-format="semantics/1.0" root="command"&gt;
   &lt;rule id="command"&gt;
      &lt;one-of&gt;
         &lt;item&gt;set&lt;/item&gt;

         &lt;item&gt;turn&lt;/item&gt;
      &lt;/one-of&gt;
      &lt;ruleref uri="#object"/&gt;
      &lt;ruleref uri="#state"/&gt;
      &lt;tag&gt;out.o=rules.object; out.s=rules.state;&lt;/tag&gt;

   &lt;/rule&gt;
   &lt;rule id="object"&gt;
      &lt;item repeat="0-1"&gt;the&lt;/item&gt;
      &lt;one-of&gt;
         &lt;item&gt;

            &lt;one-of&gt;
               &lt;item&gt;heating&lt;/item&gt;
               &lt;item&gt;cooling&lt;/item&gt;
            &lt;/one-of&gt;
            &lt;tag&gt;out="airco";&lt;/tag&gt;

         &lt;/item&gt;
         &lt;item&gt;radio&lt;tag&gt;out="radio";&lt;/tag&gt;&lt;/item&gt;
         &lt;item&gt;lights&lt;tag&gt;out="lights";&lt;/tag&gt;&lt;/item&gt;

      &lt;/one-of&gt;
   &lt;/rule&gt;
   &lt;rule id="state"&gt;
      &lt;one-of&gt;
         &lt;item&gt;to&lt;/item&gt;

         &lt;item&gt;&lt;ruleref special="NULL"/&gt;&lt;/item&gt;
      &lt;/one-of&gt;
      &lt;one-of&gt;
         &lt;item&gt;on&lt;tag&gt;out="1";&lt;/tag&gt;&lt;/item&gt;

         &lt;item&gt;off&lt;tag&gt;out="0";&lt;/tag&gt;&lt;/item&gt;
         &lt;item&gt;warm&lt;tag&gt;out="w";&lt;/tag&gt;&lt;/item&gt;
         &lt;item&gt;cool&lt;tag&gt;out="c";&lt;/tag&gt;&lt;/item&gt;

         &lt;item&gt;cold&lt;tag&gt;out="c";&lt;/tag&gt;&lt;/item&gt;
      &lt;/one-of&gt;
   &lt;/rule&gt;
&lt;/grammar&gt;
</pre>

  <p>or equivalent ABNF Form grammar</p>
  <pre class="abnf">
#ABNF 1.0;
language en-US;
tag-format &lt;semantics/1.0&gt;;
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">
&lt;grammar version="1.0" xmlns="http://www.w3.org/2001/06/grammar"
         xml:lang="en-US" tag-format="semantics/1.0-literals" root="a"&gt;
   &lt;rule id="a"&gt;
      &lt;item repeat="1-"&gt;&lt;ruleref uri="#b"/&gt;&lt;/item&gt;

      &lt;ruleref uri="#c"/&gt;
      &lt;one-of&gt;
         &lt;item&gt;
            &lt;item repeat="0-1"&gt;t1&lt;/item&gt;
            &lt;tag&gt;tag1&lt;/tag&gt;

         &lt;/item&gt;
         &lt;item&gt;
            &lt;ruleref uri="#d"/&gt;
            &lt;tag&gt;tag2&lt;/tag&gt;
         &lt;/item&gt;

      &lt;/one-of&gt;
   &lt;/rule&gt;
   &lt;rule id="b"&gt;
      &lt;one-of&gt;
         &lt;item&gt;t2&lt;/item&gt;

         &lt;item&gt;t3&lt;tag&gt;tag3&lt;/tag&gt;&lt;/item&gt;
         &lt;item&gt;t4&lt;/item&gt;
      &lt;/one-of&gt;
   &lt;/rule&gt;

   &lt;rule id="c"&gt;
      &lt;item repeat="1-2"&gt;t5&lt;tag&gt;tag5&lt;/tag&gt;&lt;/item&gt;
   &lt;/rule&gt;
   &lt;rule id="d"&gt;

      t6 &lt;ruleref uri="#c"/&gt;
   &lt;/rule&gt;
&lt;/grammar&gt;
</pre>

  <p>or equivalently in ABNF Form:</p>

  <pre class="abnf">

#ABNF 1.0;
language en-US;
tag-format &lt;semantics/1.0-literals&gt;;
root $a;
$a = ($b)&lt;1-&gt; $c (t1)&lt;0-1&gt; {tag1} | $d {tag2};
$b = t2 | t3 {tag3} | t4;
$c = (t5 {tag5})&lt;1-2&gt;;
$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">
&lt;rule id="fromto"&gt;
   from
   &lt;ruleref uri="#city"/&gt;
   &lt;tag&gt;out.fromcity=rules.city.name;&lt;/tag&gt;

   to
   &lt;ruleref uri="#city"/&gt;
   &lt;tag&gt;out.tocity=meta.city.text;&lt;/tag&gt;
&lt;/rule&gt;
</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">
&lt;rule id="a"&gt;
   &lt;ruleref uri="#b"/&gt;
   &lt;item repeat="0-1"&gt;&lt;ruleref uri="#b"/&gt;&lt;/item&gt;

   &lt;tag&gt;out.x=rules.b.x;&lt;/tag&gt;
&lt;/rule&gt;
</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">
&lt;rule id="a"&gt;
   &lt;ruleref uri="#b"/&gt;
   &lt;item repeat="0-1"&gt;&lt;ruleref uri="#c"/&gt;&lt;/item&gt;
   &lt;tag&gt;out.x=rules.c; out.y=rules.d; out.z=rules.e;&lt;/tag&gt;

   &lt;ruleref uri="#e"/&gt;
&lt;/rule&gt;
</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">
&lt;rule id="a"&gt;
   &lt;ruleref uri="#b"/&gt;
   &lt;tag&gt;out.y=rules.b.x;&lt;/tag&gt;

   &lt;item repeat="0-1"&gt;
      &lt;ruleref uri="#b"/&gt;&lt;tag&gt;out.y=out.y+rules.b.x;&lt;/tag&gt;
   &lt;/item&gt;
&lt;/rule&gt;
&lt;rule id="b"&gt;
   foo
   &lt;tag&gt;out.x=1;&lt;/tag&gt;

   &lt;one-of&gt;
      &lt;item&gt;bar&lt;tag&gt;out.x=3;&lt;/tag&gt;&lt;/item&gt;
      &lt;item&gt;
         &lt;item repeat="1-"&gt;boo&lt;tag&gt;out.x=out.x+1;&lt;/tag&gt;&lt;/item&gt;

      &lt;/item&gt;
   &lt;/one-of&gt;
&lt;/rule&gt;
</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;})&lt;1-&gt;);

</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">
&lt;rule id="a"&gt;
   &lt;ruleref uri="#b"/&gt;

   &lt;ruleref uri="#c"/&gt;
   &lt;tag&gt;out.x = rules.b.x + rules.c.x;&lt;/tag&gt;
&lt;/rule&gt;
</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">
&lt;rule id="a"&gt;
   &lt;ruleref uri="#b"/&gt;
   &lt;tag&gt;out.x = rules.b.x + rules.c.x;&lt;/tag&gt;
   &lt;ruleref uri="#c"/&gt;
&lt;/rule&gt;

</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">
&lt;rule id="a"&gt;
   &lt;item repeat="0-1"&gt;&lt;ruleref uri="#b"/&gt;&lt;/item&gt;
   &lt;ruleref uri="#c"/&gt;
   &lt;tag&gt;out.x = rules.b.x + rules.c.x;&lt;/tag&gt;

&lt;/rule&gt;
</pre>

  <p>A safer way to write this rule could be (assuming
  <code>x</code> is of type Number):</p>

  <pre class="xml">
&lt;rule id="a"&gt;
   &lt;tag&gt;out.x=0;&lt;/tag&gt;

   &lt;item repeat="0-1"&gt;&lt;ruleref uri="#b"/&gt;&lt;tag&gt;out.x=rules.b.x;&lt;/tag&gt;&lt;/item&gt;
   &lt;ruleref uri="#c"/&gt;
   &lt;tag&gt;out.x = out.x + rules.c.x;&lt;/tag&gt;
&lt;/rule&gt;

</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">
&lt;rule id="a"&gt;
   &lt;item repeat="1-"&gt;&lt;ruleref uri="#b"/&gt;&lt;/item&gt;

   &lt;ruleref uri="#c"/&gt;
   &lt;tag&gt;out.x=rules.b.x+rules.c.x;&lt;/tag&gt;
&lt;/rule&gt;
</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">
&lt;rule id="a"&gt;
   &lt;item repeat="1-"&gt;
      &lt;ruleref uri="#b"/&gt;&lt;tag&gt;out.x=out.x+rules.b.x;&lt;/tag&gt;
   &lt;/item&gt;

   &lt;ruleref uri="#c"/&gt;
   &lt;tag&gt;out.x=out.x+rules.c.x;&lt;/tag&gt;
&lt;/rule&gt;
</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">
&lt;rule id="a"&gt;
   &lt;item repeat="0-"&gt;&lt;ruleref uri="#b"/&gt;&lt;ruleref uri="#d"/&gt;&lt;/item&gt;
   &lt;ruleref uri="#c"/&gt;
   &lt;tag&gt;out.x=rules.b+rules.c.x;&lt;/tag&gt;

&lt;/rule&gt;
</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">
&lt;rule id="a"&gt;

   &lt;one-of&gt;
      &lt;item&gt;&lt;ruleref uri="#b"/&gt;&lt;/item&gt;
      &lt;item&gt;&lt;ruleref uri="#c"/&gt;&lt;/item&gt;
   &lt;/one-of&gt;
   &lt;tag&gt;out.x=rules.b.x+rules.c.x;&lt;/tag&gt;

&lt;/rule&gt;
</pre>

  <p>This could be better written as:</p>
  <pre class="xml">
&lt;rule id="a"&gt;
   &lt;one-of&gt;
      &lt;item&gt;&lt;ruleref uri="#b"/&gt;&lt;tag&gt;out.x=rules.b.x;&lt;/tag&gt;&lt;/item&gt;

      &lt;item&gt;&lt;ruleref uri="#c"/&gt;&lt;tag&gt;out.x=rules.c.x;&lt;/tag&gt;&lt;/item&gt;
   &lt;/one-of&gt;
&lt;/rule&gt;
</pre>

  <p>The <code>rules.b.x</code> refers to whichever
  <code>rules.b</code> actually matched:</p>

  <pre class="xml">
&lt;rule id="a"&gt;
   &lt;one-of&gt;
      &lt;item&gt;&lt;ruleref uri="#b"/&gt; a&lt;/item&gt;
      &lt;item&gt;a &lt;ruleref uri="#b"/&gt;&lt;/item&gt;

   &lt;/one-of&gt;
   &lt;ruleref uri="#c"/&gt;
   &lt;tag&gt;out.x=rules.b.x+rules.c.x;&lt;/tag&gt;
&lt;/rule&gt;
</pre>

  <p>One of the operands to every addition causes a run-time error
  here depending on the input utterance:</p>

  <pre class="xml">
&lt;rule id="a"&gt;
   &lt;one-of&gt;
      &lt;item&gt;&lt;ruleref uri="#b"/&gt;&lt;/item&gt;
      &lt;item&gt;&lt;ruleref uri="#c"/&gt;&lt;/item&gt;

   &lt;/one-of&gt;
   &lt;one-of&gt;
      &lt;item&gt;&lt;ruleref uri="#d"/&gt;&lt;/item&gt;
      &lt;item&gt;&lt;ruleref uri="#e"/&gt;&lt;/item&gt;
   &lt;/one-of&gt;

   &lt;tag&gt;out.x=(rules.b.x+rules.c.x) * (rules.d.x+rules.e.x);&lt;/tag&gt;
&lt;/rule&gt;
</pre>

  <p>This rule can be better written as:</p>

  <pre class="xml">
&lt;rule id="a"&gt;

   &lt;one-of&gt;
      &lt;item&gt;&lt;ruleref uri="#b"/&gt;&lt;tag&gt;out.x=rules.b.x;&lt;/tag&gt;&lt;/item&gt;
      &lt;item&gt;&lt;ruleref uri="#c"/&gt;&lt;tag&gt;out.x=rules.c.x;&lt;/tag&gt;&lt;/item&gt;

   &lt;/one-of&gt;
   &lt;one-of&gt;
      &lt;item&gt;&lt;ruleref uri="#d"/&gt;&lt;tag&gt;out.x=out.x*rules.d.x;&lt;/tag&gt;&lt;/item&gt;
      &lt;item&gt;&lt;ruleref uri="#e"/&gt;&lt;tag&gt;out.x=out.x*rules.e.x;&lt;/tag&gt;&lt;/item&gt;

   &lt;/one-of&gt;
&lt;/rule&gt;
</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">
&lt;rule id="a"&gt;
   &lt;one-of&gt;
      &lt;item&gt;&lt;ruleref uri="#b"/&gt;&lt;/item&gt;
      &lt;item&gt;&lt;ruleref uri="#c"/&gt;&lt;tag&gt;out.x=rules.b.x+rules.c.x;&lt;/tag&gt;&lt;/item&gt;

   &lt;/one-of&gt;
&lt;/rule&gt;
</pre>

  <p>A more useful rule could be:</p>
  <pre class="xml">
&lt;rule id="a"&gt;
   &lt;one-of&gt;

      &lt;item&gt;&lt;ruleref uri="#b"/&gt;&lt;tag&gt;out.x=rules.b.x;&lt;/tag&gt;&lt;/item&gt;
      &lt;item&gt;&lt;ruleref uri="#c"/&gt;&lt;tag&gt;out.x=rules.c.x;&lt;/tag&gt;&lt;/item&gt;
   &lt;/one-of&gt;

&lt;/rule&gt;
</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">
&lt;rule id="a"&gt;
   &lt;ruleref uri="#b"/&gt;
   &lt;item repeat="0-1"&gt;
      &lt;ruleref uri="#c"/&gt;
      &lt;tag&gt;out.x=rules.b.x+rules.c.x;&lt;/tag&gt;

   &lt;/item&gt;
&lt;/rule&gt;
</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">
&lt;rule id="a"&gt;
   &lt;ruleref uri="#b"/&gt;
   &lt;item repeat="1-"&gt;
      &lt;ruleref uri="#c"/&gt;
      &lt;tag&gt;out.x = rules.b.x + rules.c.x;&lt;/tag&gt;

   &lt;/item&gt;
&lt;/rule&gt;
</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">
&lt;rule id="a"&gt;

   &lt;ruleref uri="#b"/&gt;
   &lt;item repeat="0-"&gt;
      &lt;ruleref uri="#c"/&gt;
      &lt;tag&gt;out.x = rules.b.x + rules.c.x;&lt;/tag&gt;
   &lt;/item&gt;

&lt;/rule&gt;
</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">
&lt;rule id="digits"&gt;
   &lt;tag&gt;out.ds="";&lt;/tag&gt;
   &lt;item repeat="1-"&gt;
      &lt;ruleref uri="#digit"/&gt;
      &lt;tag&gt;out.ds = out.ds + rules.digit;&lt;/tag&gt;

   &lt;/item&gt;
&lt;/rule&gt;
&lt;rule id="digit"&gt;
   &lt;one-of&gt;
      &lt;item&gt;"0"&lt;/item&gt;
      &lt;item&gt;"1"&lt;/item&gt;

      &lt;item&gt;"2"&lt;/item&gt;
      &lt;item&gt;"3"&lt;/item&gt;
      &lt;item&gt;"4"&lt;/item&gt;
      &lt;item&gt;"5"&lt;/item&gt;

      &lt;item&gt;"6"&lt;/item&gt;
      &lt;item&gt;"7"&lt;/item&gt;
      &lt;item&gt;"8"&lt;/item&gt;
      &lt;item&gt;"9"&lt;/item&gt;

   &lt;/one-of&gt;
&lt;/rule&gt;
</pre>

  <p>The <code>rules.latest()</code> resolves to
  <code>rules.c</code>:</p>

  <pre class="xml">

&lt;rule id="a"&gt;
   &lt;ruleref uri="#b"/&gt;
   &lt;ruleref uri="#c"/&gt;
   &lt;tag&gt;out=rules.latest();&lt;/tag&gt;
&lt;/rule&gt;
</pre>

  <p>The <code>rules.latest()</code> resolves to
  <code>rules.b</code>:</p>
  <pre class="xml">
&lt;rule id="a"&gt;
   &lt;ruleref uri="#c"/&gt;
   &lt;ruleref uri="#b"/&gt;

   &lt;tag&gt;out=rules.latest();&lt;/tag&gt;
&lt;/rule&gt;
</pre>

  <p>The <code>rules.latest()</code> returns
  <code>undefined</code>:</p>

  <pre class="xml">
&lt;rule id="a"&gt;
   b c
   &lt;tag&gt;out=rules.latest();&lt;/tag&gt;
&lt;/rule&gt;
</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">
&lt;rule id="x"&gt;

   &lt;ruleref uri="#a"/&gt;
   &lt;one-of&gt;
      &lt;item&gt;&lt;ruleref uri="#b"/&gt;&lt;/item&gt;
      &lt;item&gt;&lt;ruleref uri="#c"/&gt;&lt;/item&gt;
   &lt;/one-of&gt;

   &lt;tag&gt;out=rules.latest();&lt;/tag&gt;
&lt;/rule&gt;
</pre>

  <p>This is equivalent to:</p>

  <pre class="xml">
&lt;rule id="x"&gt;

   &lt;ruleref uri="#a"/&gt;
   &lt;one-of&gt;
      &lt;item&gt;&lt;ruleref uri="#b"/&gt;&lt;tag&gt;out=rules.latest();&lt;/tag&gt;&lt;/item&gt;
      &lt;item&gt;&lt;ruleref uri="#c"/&gt;&lt;tag&gt;out=rules.latest();&lt;/tag&gt;&lt;/item&gt;

   &lt;/one-of&gt;
&lt;/rule&gt;
</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">
&lt;rule id="x"&gt;
   &lt;ruleref uri="#a"/&gt;
   &lt;item repeat="0-1"&gt;&lt;ruleref uri="#b"/&gt;&lt;/item&gt;
   &lt;tag&gt;out=rules.latest();&lt;/tag&gt;

&lt;/rule&gt;
</pre>

  <p>The effect is equivalent to:</p>
  <pre class="xml">
&lt;rule id="x"&gt;
   &lt;ruleref uri="#a"/&gt;&lt;tag&gt;out=rules.latest();&lt;/tag&gt;

   &lt;item repeat="0-1"&gt;&lt;ruleref uri="#b"/&gt;&lt;tag&gt;out=rules.latest();&lt;/tag&gt;&lt;/item&gt;
&lt;/rule&gt;
</pre>

  <p>The <code>rules.latest()</code> resolves to the last
  occurrence of <code>rules.a</code>:</p>

  <pre class="xml">
&lt;rule id="x"&gt;
   &lt;item repeat="1-"&gt;&lt;ruleref uri="#a"/&gt;&lt;/item&gt;
   &lt;tag&gt;out=rules.latest();&lt;/tag&gt;
&lt;/rule&gt;

</pre>

  <p>The effect is equivalent to:</p>

  <pre class="xml">
&lt;rule id="x"&gt;
   &lt;item repeat="1-"&gt;&lt;ruleref uri="#a"/&gt;&lt;tag&gt;out=rules.latest();&lt;/tag&gt;&lt;/item&gt;

&lt;/rule&gt;
</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>&lt;item&gt;</code>. Each
    <code>&lt;item&gt;</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>&lt;item&gt;</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 &lt; and &amp;, 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>&lt;item&gt;</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">
&lt;drink&gt;
   &lt;liquid&gt;coke&lt;/liquid&gt;

   &lt;drinksize&gt;medium&lt;/drinksize&gt;
&lt;/drink&gt;
&lt;pizza&gt;
   &lt;number&gt;3&lt;/number&gt;
   &lt;pizzasize&gt;large&lt;/pizzasize&gt;

   &lt;topping length="2"&gt;
      &lt;item index="0"&gt;pepperoni&lt;/item&gt;
      &lt;item index="1"&gt;mushrooms&lt;/item&gt;
   &lt;/topping&gt;
&lt;/pizza&gt;

</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">

...
&lt;martini method="shaken"&gt;
   &lt;gin ratio="8"&gt;Bombay Sapphire&lt;/gin&gt;
   &lt;vermouth ratio="1"&gt;Noilly Prat&lt;/vermouth&gt;
&lt;/martini&gt;
...
</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>&lt;item&gt;</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">

&lt;n1:drink xmlns:n1="http://www.example.com/n1"&gt;
   &lt;liquid n2:color="black" xmlns:n2="http://www.example.com/n2"&gt;coke&lt;/liquid&gt;
   &lt;size&gt;medium&lt;/size&gt;
&lt;/n1:drink&gt;
</pre>

  <p>Note that the <code>_nsprefix</code> property only applies to
  its parent object and hence neither the
  <code>&lt;liquid&gt;</code> element nor the
  <code>&lt;size&gt;</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">
&lt;?xml version="1.0" encoding="UTF-8"?&gt;

&lt;!DOCTYPE grammar PUBLIC "-//W3C//DTD GRAMMAR 1.0//EN"
                  "http://www.w3.org/TR/speech-grammar/grammar.dtd"&gt;
&lt;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"&gt;
   &lt;rule id="order"&gt;
      I would like a
      &lt;ruleref uri="#drink"/&gt;
      &lt;tag&gt;out.drink = new Object(); out.drink.liquid=rules.drink.type;
           out.drink.drinksize=rules.drink.drinksize;&lt;/tag&gt;
      and
      &lt;ruleref uri="#pizza"/&gt;

      &lt;tag&gt;out.pizza=rules.pizza;&lt;/tag&gt;
   &lt;/rule&gt;
   &lt;rule id="kindofdrink"&gt;
      &lt;one-of&gt;
         &lt;item&gt;coke&lt;/item&gt;

         &lt;item&gt;pepsi&lt;/item&gt;
         &lt;item&gt;coca cola&lt;tag&gt;out="coke";&lt;/tag&gt;&lt;/item&gt;
      &lt;/one-of&gt;
   &lt;/rule&gt;

   &lt;rule id="foodsize"&gt;
      &lt;tag&gt;out="medium";&lt;/tag&gt; &lt;!-- "medium" is default if nothing said --&gt;
      &lt;item repeat="0-1"&gt;
         &lt;one-of&gt;
            &lt;item&gt;small&lt;tag&gt;out="small";&lt;/tag&gt;&lt;/item&gt;

            &lt;item&gt;medium&lt;/item&gt;
            &lt;item&gt;large&lt;tag&gt;out="large";&lt;/tag&gt;&lt;/item&gt;
            &lt;item&gt;regular&lt;tag&gt;out="medium";&lt;/tag&gt;&lt;/item&gt;

         &lt;/one-of&gt;
      &lt;/item&gt;
   &lt;/rule&gt;

   &lt;!-- Construct Array of toppings, return Array --&gt;
   &lt;rule id="tops"&gt;
      &lt;tag&gt;out=new Array;&lt;/tag&gt;

      &lt;ruleref uri="#top"/&gt;
      &lt;tag&gt;out.push(rules.top);&lt;/tag&gt;
      &lt;item repeat="1-"&gt;
         and
         &lt;ruleref uri="#top"/&gt;
         &lt;tag&gt;out.push(rules.top);&lt;/tag&gt;

      &lt;/item&gt;
   &lt;/rule&gt;
   &lt;rule id="top"&gt;
      &lt;one-of&gt;
         &lt;item&gt;anchovies&lt;/item&gt;

         &lt;item&gt;pepperoni&lt;/item&gt;
         &lt;item&gt;mushroom&lt;tag&gt;out="mushrooms";&lt;/tag&gt;&lt;/item&gt;
         &lt;item&gt;mushrooms&lt;/item&gt;

      &lt;/one-of&gt;
   &lt;/rule&gt;

   &lt;!-- Two properties (drinksize, type) on left hand side Rule Variable --&gt;
   &lt;rule id="drink"&gt;
      &lt;ruleref uri="#foodsize"/&gt;
      &lt;ruleref uri="#kindofdrink"/&gt;

      &lt;tag&gt;out.drinksize=rules.foodsize; out.type=rules.kindofdrink;&lt;/tag&gt;
   &lt;/rule&gt;

   &lt;!-- Three properties on rules.pizza --&gt;
   &lt;rule id="pizza"&gt;
      &lt;ruleref uri="#number"/&gt;

      &lt;ruleref uri="#foodsize"/&gt;
      &lt;tag&gt;out.pizzasize=rules.foodsize; out.number=rules.number;&lt;/tag&gt;
      pizzas with
      &lt;ruleref uri="#tops"/&gt;
      &lt;tag&gt;out.topping=rules.tops;&lt;/tag&gt;

   &lt;/rule&gt;
   &lt;rule id="number"&gt;
      &lt;one-of&gt;
         &lt;item&gt;
            &lt;tag&gt;out=1;&lt;/tag&gt;

            &lt;one-of&gt;
               &lt;item&gt;a&lt;/item&gt;
               &lt;item&gt;one&lt;/item&gt;
            &lt;/one-of&gt;
         &lt;/item&gt;

         &lt;item&gt;two&lt;tag&gt;out=2;&lt;/tag&gt;&lt;/item&gt;
         &lt;item&gt;three&lt;tag&gt;out=3;&lt;/tag&gt;&lt;/item&gt;
      &lt;/one-of&gt;

   &lt;/rule&gt;
&lt;/grammar&gt;
</pre>

  <h5 class="qualif">ABNF Form</h5>
  <pre class="abnf">
#ABNF 1.0 UTF-8;
language en;
mode voice;
tag-format &lt;semantics/1.0&gt;;
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);})&lt;1-&gt;;
$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">
&lt;?xml version="1.0" encoding="UTF-8"?&gt;
&lt;!DOCTYPE grammar PUBLIC "-//W3C//DTD GRAMMAR 1.0//EN"
                  "http://www.w3.org/TR/speech-grammar/grammar.dtd"&gt;
&lt;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"&gt;
   &lt;rule id="main"&gt;
      &lt;one-of&gt;
         &lt;item&gt;

            &lt;ruleref uri="#sub_hundred_thousand"/&gt;
            &lt;tag&gt;out = rules.sub_hundred_thousand;&lt;/tag&gt;
         &lt;/item&gt;
         &lt;item&gt;
            &lt;ruleref uri="#sub_thousand"/&gt;

            &lt;tag&gt;out = rules.sub_thousand;&lt;/tag&gt;
         &lt;/item&gt;
         &lt;item&gt;
            &lt;ruleref uri="#sub_hundred"/&gt;
            &lt;tag&gt;out = rules.sub_hundred;&lt;/tag&gt;

         &lt;/item&gt;
      &lt;/one-of&gt;
   &lt;/rule&gt;
   &lt;rule id="sub_hundred_thousand"&gt;
      &lt;ruleref uri="#sub_hundred"/&gt;
      &lt;tag&gt;out = (1000 * rules.sub_hundred)&lt;/tag&gt;

      thousand
      &lt;item repeat="0-1"&gt;
          &lt;item repeat="0-1"&gt;and&lt;/item&gt;
          &lt;ruleref uri="#sub_thousand"/&gt;&lt;tag&gt;out += rules.sub_thousand;&lt;/tag&gt;
      &lt;/item&gt;

   &lt;/rule&gt;
   &lt;rule id="sub_thousand"&gt;
      &lt;ruleref uri="#sub_hundred"/&gt;
      &lt;tag&gt;out = (100 * rules.sub_hundred);&lt;/tag&gt;
      hundred
      &lt;item repeat="0-1"&gt;

          &lt;item repeat="0-1"&gt;and&lt;/item&gt;
          &lt;ruleref uri="#sub_hundred"/&gt;&lt;tag&gt;out += rules.sub_hundred;&lt;/tag&gt;
      &lt;/item&gt;
   &lt;/rule&gt;

   &lt;rule id="sub_hundred"&gt;
      &lt;tag&gt;out = 0;&lt;/tag&gt;
      &lt;one-of&gt;
         &lt;item&gt;zero&lt;/item&gt;
         &lt;item&gt;&lt;ruleref uri="#teens"/&gt;&lt;tag&gt;out += rules.teens;&lt;/tag&gt;&lt;/item&gt;

         &lt;item&gt;
            &lt;ruleref uri="#tens"/&gt;&lt;tag&gt;out += rules.tens;&lt;/tag&gt;
            &lt;item repeat="0-1"&gt;
               &lt;ruleref uri="#digit"/&gt;
               &lt;tag&gt;out += rules.digit;&lt;/tag&gt;

            &lt;/item&gt;
         &lt;/item&gt;
         &lt;item&gt;&lt;ruleref uri="#digit"/&gt;&lt;tag&gt;out += rules.digit;&lt;/tag&gt;&lt;/item&gt;
      &lt;/one-of&gt;

   &lt;/rule&gt;
   &lt;rule id="tens"&gt;
      &lt;one-of&gt;
         &lt;item&gt;twenty&lt;tag&gt;out = 20;&lt;/tag&gt;&lt;/item&gt;

         &lt;item&gt;thirty&lt;tag&gt;out = 30;&lt;/tag&gt;&lt;/item&gt;
         &lt;item&gt;forty&lt;tag&gt;out = 40;&lt;/tag&gt;&lt;/item&gt;
         &lt;item&gt;fifty&lt;tag&gt;out = 50;&lt;/tag&gt;&lt;/item&gt;

         &lt;item&gt;sixty&lt;tag&gt;out = 60;&lt;/tag&gt;&lt;/item&gt;
         &lt;item&gt;seventy&lt;tag&gt;out = 70;&lt;/tag&gt;&lt;/item&gt;
         &lt;item&gt;eighty&lt;tag&gt;out = 80;&lt;/tag&gt;&lt;/item&gt;

         &lt;item&gt;ninety&lt;tag&gt;out = 90;&lt;/tag&gt;&lt;/item&gt;
      &lt;/one-of&gt;
   &lt;/rule&gt;
   &lt;rule id="teens"&gt;

      &lt;one-of&gt;
         &lt;item&gt;ten&lt;tag&gt;out = 10;&lt;/tag&gt;&lt;/item&gt;
         &lt;item&gt;eleven&lt;tag&gt;out = 11;&lt;/tag&gt;&lt;/item&gt;

         &lt;item&gt;twelve&lt;tag&gt;out = 12;&lt;/tag&gt;&lt;/item&gt;
         &lt;item&gt;thirteen&lt;tag&gt;out = 13;&lt;/tag&gt;&lt;/item&gt;
         &lt;item&gt;fourteen&lt;tag&gt;out = 14;&lt;/tag&gt;&lt;/item&gt;

         &lt;item&gt;fifteen&lt;tag&gt;out = 15;&lt;/tag&gt;&lt;/item&gt;
         &lt;item&gt;sixteen&lt;tag&gt;out = 16;&lt;/tag&gt;&lt;/item&gt;
         &lt;item&gt;seventeen&lt;tag&gt;out = 17;&lt;/tag&gt;&lt;/item&gt;

         &lt;item&gt;eighteen&lt;tag&gt;out = 18;&lt;/tag&gt;&lt;/item&gt;
         &lt;item&gt;nineteen&lt;tag&gt;out = 19;&lt;/tag&gt;&lt;/item&gt;
      &lt;/one-of&gt;

   &lt;/rule&gt;
   &lt;rule id="digit"&gt;
      &lt;one-of&gt;
         &lt;item&gt;one&lt;tag&gt;out = 1;&lt;/tag&gt;&lt;/item&gt;

         &lt;item&gt;two&lt;tag&gt;out = 2;&lt;/tag&gt;&lt;/item&gt;
         &lt;item&gt;three&lt;tag&gt;out = 3;&lt;/tag&gt;&lt;/item&gt;
         &lt;item&gt;four&lt;tag&gt;out = 4;&lt;/tag&gt;&lt;/item&gt;

         &lt;item&gt;five&lt;tag&gt;out = 5;&lt;/tag&gt;&lt;/item&gt;
         &lt;item&gt;six&lt;tag&gt;out = 6;&lt;/tag&gt;&lt;/item&gt;
         &lt;item&gt;seven&lt;tag&gt;out = 7;&lt;/tag&gt;&lt;/item&gt;

         &lt;item&gt;eight&lt;tag&gt;out = 8;&lt;/tag&gt;&lt;/item&gt;
         &lt;item&gt;nine&lt;tag&gt;out = 9;&lt;/tag&gt;&lt;/item&gt;
      &lt;/one-of&gt;

   &lt;/rule&gt;
&lt;/grammar&gt;
</pre>

  <h5 class="qualif">ABNF Form</h5>
  <pre class="abnf">
#ABNF 1.0 UTF-8;
language en;
mode voice;
tag-format &lt;semantics/1.0&gt;;
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>