W3C

Semantic Interpretation for Speech Recognition (SISR) Version 1.0
Implementation Report Plan

Version: January 11, 2006

Contributors
Dave Burke, Voxpilot (Chief Editor)
Emily Candell, Comverse
Alex Lee, VoiceGenie
Brien Muschett, IBM
Christopher Passaretti, Nortel
Paola Rossi, Loquendo

Copyright ©2006 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.

Table of Contents

1. Introduction

The W3C Semantic Interpretation for Speech Recognition (SISR) Version 1.0 Specification entered the Candidate Recommendation period on 11 January 2006.

The planned date for entering Proposed Recommendation is 20 February 2006. Preparation of an Implementation Report is a key criteria for moving beyond the Candidate Recommendation. This document describes the requirements for the Implementation Report and the process that the Voice Browser Working Group will follow in preparing the report.

1.1 Implementation Report Objectives

  1. Must verify that the specification is implementable.
  2. Must demonstrate interoperability of implementations of the specification.

1.2 Implementation Report Non-objectives

  1. The IR does not attempt conformance testing of implementations.

2. Work During the Candidate Recommendation Period

During the CR period, the Working Group will carry out the following activities:

  1. Clarification and improvement of the exposition of the specification.
  2. Disposing of Comments that were communicated to the WG during the CR period.
  3. Preparation of an Implementation Report meeting the criteria outlined in this document.

3. Participating in the Implementation Report

You are invited to contribute to the assessment of the W3C SISR 1.0 Specification by participating in the Implementation Report process.

4. Entrance Criteria to PR

The VBWG established the following entrance criteria to Proposed Recommendation in the Request for CR:

  1. Sufficient reports of implementation experience have been gathered to demonstrate that SISR processors based on the specification are implementable and have compatible behavior.
  2. Specific Implementation Report requirements (outlined below) have been met.
  3. Formal responses to all comments received by the Working Group.

5. Implementation Report Requirements

5.1 Detailed requirements for Implementation Report

  1. Testimonials from implementers will be included in the IR when provided to document the utility and implementability of the specification.
  2. IR must cover all specified features in the specification. For each feature the IR should indicate:
  3. Feature status is a factor in test coverage in the report:

5.2 Out of Scope

  1. IR will not cover SRGS processor conformance.
  2. IR will not cover speech recognition performance.

6. Systems

Note: The testimonials with pink background from "Acme Labs" and "Beta Inc." are just examples and will be replaced with the actually submitted testimonials.

Acme Labs

Executive Summary

The W3C SISR 1.0 Specification is well-written, easily implementable and extremly useful. Acme Labs used it to make waffles, to transcribe telephone calls, to chase roadrunners, and to straighten the Tower of Pisa.

Beta Inc.

Executive Summary

The W3C SISR 1.0 Specification is extremly useful, easily implementable and well-written. Beta Inc. used it to make waffles, to transcribe telephone calls, to chase roadrunners, and to straighten the Tower of Pisa.

7. Test Results

The following table lists the assertions that were derived from the SISR 1.0 Specification. The Assertion ID column uniquely identifies the assertion and links to a corresponding test. The Spec column identifies the section of the specification from which the assertion was derived. The Required column indicates whether or not the spec requires the platform to implement the feature described by the assertion. The Automatable column indicates whether or not the associated test can be automated or requires manual execution. The Assertion column describes the assertion.

Note: An anonymous column for each company that runs the test suite will be added, and each cell will specify "pass" or "fail" to reflect actual submitted implementation results.

Assertion IDSpecRequiredAutomatableAssertion
2 [4.2] Yes. Yes. The header of an SRGS 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.
3 [4.2] Yes. Yes. Global tags are ignored in Grammars using the String Literal tag syntax.
4 [4.2] Yes. Yes. The SI Tags are evaluated only once, in a global scope that will be shared by all evaluations.
5 [4.2] Yes. Yes. SI Tags in the grammar header have write access to the global scope to inizialize it.
6 [5] Yes. Yes. For a given parse, if there is no SI Tag attached to the expansion in the grammar rule and there are no rule references in the parse, the value for the text meta variable is automatically copied into the Rule Variable 'out' (which then becomes of type string). Applied to semantic literals.
7 [5] Yes. Yes. 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 if there is at least one rule reference, the value of the Rule Variable of the last rule reference in the parse is automatically copied into the Rule Variable.Applied to semantic literals.
8 [3.3.1] Yes. Yes. Every grammar rule has a single Rule Variable that holds an ECMAScript Compact Profile variable.
9 [3.3.1] Yes. Yes. The Rule Variable can be evaluated.
10 [3.3.1] Yes. Yes. The Rule Variable can be assigned to.
11 [3.3.1] Yes. Yes. The Rule Variable is identified by 'out'.
13 [3.3.1] Yes. Yes. Properties of the Rule Variable can be individually accessed by out.Identifier where Identifier is the name of the property.
15 [3.3.2] Yes. Yes. 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.
16 [3.3.2] Yes. Yes. Rule Variables associated to a rule reference can be evaluated.
17 [3.3.2] Yes. Yes. Rule Variables associated to referenced rules can be assigned to.
18 [3.3.2] Yes. Yes. The Rule Variable associated to a rule reference is identified by rules.Rulename, where Rulename is the rulename of the rule, as defined in SRGS Section 3.1 Basic Rule Definition.
20 [3.3.2] Yes. Yes. Individual properties of a Rule Variable.Identifier can be identified by rules.Rulename, where Rulename is the name of the rule and Identifier is the name of the property.
22 [3.3.2] Yes. Yes. Every SI Script has access to a rules object that has a property holding the Rule Variable value for every visible rule; the property name is the name of the rule to which the Rule Variable is associated.
23 [3.3.2] Yes. Yes. 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 be referenced through rules.latest().
25 [3.3.2] Yes. Yes. In an expression, the Rule Variable of the current grammar rule can be evaluated.
26 [3.3.2] Yes. Yes. In an expression, the Rule Variable of the current grammar rule can be assigned to.
27 [3.3.2] Yes. Yes. In an expression, the rule variables of the referenced rules can be evaluated.
28 [3.3.2] Yes. Yes. In an expression, the rule variables of the referenced rules can be assigned to.
29 [3.3.2] Yes. Yes. Special Rule NULL can not be evaluated.
30 [3.3.3] Yes. Yes. A Rule Variable's text variable is identified by meta.rulename.text, where rulename is the name of the Rule Variable.
32 [3.3.3] Yes. Yes. The text variable of the Rule Variable referred to by rules.latest() is identified by meta.latest().text.
36 [3.3.3] Yes. Yes. The text variable associated to the current grammar rule is identified by meta.current().text.
38 [3.3.3] Yes. Yes. The text variable of the current grammar is read only.
39 [3.3.3] Yes. Yes. A Rule Variable's score variable is identified by meta.rulename.score, where rulename is the name of Rule Variable.
41 [3.3.3] Yes. Yes. The score variable of the Rule Variable referred to by rules.latest() is identified by meta.latest().score.
45 [3.3.3] Yes. Yes. The score variable associated to the current grammar rule is identified by meta.current().score.
47 [3.3.3] Yes. Yes. The score variable of the current grammar rule is read-only.
48 [6.3] Yes. Yes. 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.
49 [6.3] Yes. Yes. During evaluation of a script in the flat parse list, the global scope is accessible for reading only.
50 [6.3] Yes. Yes. The tags within a flat parse are executed in the order in which they appear, left to right.
51 [6.3] Yes. Yes. The global tags (in the grammar header) are executed in document order.
52 [6.3] Yes. Yes. 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.
53 [6.3] Yes. Yes. The ECMAScript scope chains always have the global scope (the scope of the whole parse) as top-level object, and the scope belonging to the parse list as successor.
54 [6.3] Yes. Yes. Access to variables in tag executions are resolved with the scope chain according to the ECMAScript rules.
55 [6.3] Yes. Yes. The variables object according to ES-CP 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.
56 [6.3] Yes. Yes. When the environment of a new scope is set up, the variable out is initialized as an empty object.
59 [6.3] Yes. Yes. When the environment of a new scope is set up, meta.current().text is initialized (read-only) to the text variable of the current grammar rule.
61 [6.3] Yes. Yes. When the environment of a new scope is set up, meta.score is initialized (read-only) to the score value related to the current grammar rule
62 [6.3] Yes. Yes. When execution of the flat parse is finished, the scope object of this flat parse is removed from the scope chain .
64 [6.3] Yes. Yes. When execution of the flat parse is finished, rules.rulename of the scope of the referencing rule, where rulename is the name of the referenced rule, is set to the value of the variable out of the child scope.
68 [6.3] Yes. Yes. When execution of the flat parse is finished, rules.latest() = rules.rulename (both variables are in the scope of the referencing rule)
70 [6.3] Yes. Yes. When execution of the flat parse is finished, meta.latest().text = meta.rulename.text (both variables are in the scope of the referencing rule).
72 [6.3] Yes. Yes. When execution of the flat parse is finished, meta.latest().score = meta.rulename.score (both variables are in the scope of the referencing rule)
73 [6.3] Yes. Yes. Within a parse list, results of previously executed rule references that are direct child of this list are available by rules.rulename.
74 [6.3] Yes. Yes. If a rule was referenced multiple times in the same scope, the result of the last instantiation is visible.
75 [6.3] Yes. Yes. rules.latest() always refers to the result of the previous reference in the current scope.
76 [6.3] Yes. Yes. meta.latest().text refers to the corresponding text utterance
77 [6.3] Yes. Yes. meta.latest().score refers to the corresponding score value
78 [6.3] Yes. Yes. 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.
79 [6.4] Yes. Yes. Within a single SI Tag, the order of evaluation is determined by ES-CP for the evaluation of a valid ES-CP Program.
80 [6.4] Yes. Yes. All global SI Tags (in tags in the grammar header) are executed once, before any SI Tags within a grammar rule are executed
81 [6.4] Yes. Yes. 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.
82 [6.4] Yes. Yes. The flat parse list also determines how many SI elements will be generated from an SI tag that occurs in a grammar rule.
83 [6.4] Yes. Yes. Every SI Tag element in a flat parse list is evaluated exactly once.
84 [6.4] Yes. Yes. The order of evaluating String Literals is determined by the order in which the equivalent SI Tag appears in the flat parse list.
85 [6.4] Yes. Yes. 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.
94 [3.1] Yes. Yes. Every grammar rule has a single Rule Variable that holds a semantic value.
95 [3.1] Yes. Yes. SI tags also have access to the Rule Variables of any other rules referenced by the current grammar rule and already processed by that point in the utterance.
96 [3.1] Yes. Yes. The Rule Variables of other rules are referenced by the name of their grammar rule.
97 [3.1] Yes. Yes. Rule Variables can hold semantic values of any type defined in ES-CP. They are not explicitly typed.
98 [3.1] Yes. Yes. Rule Variables that have not been assigned a value are not defined
99 [3.1] Yes. Yes. For every Rule Variable there is an associated variable named "text", of type string, which holds the substring (the series of tokens) in the utterance that is governed by the corresponding grammar rule.
101 [3.1] Yes. Yes. There is an associated variable called "score", of type Number, which holds a value that is related to the confidence or probability of the corresponding grammar rule or some similar measure.
102 [3.1] Yes. Yes. Higher score values indicate higher confidence or probability over the corresponding grammar rule.
104 [3.1] Yes. Yes. 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. EMMA), this value is serialized into an XML document.
105 [3.2] Yes. Yes. The two different possible values of the tag-format 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. Script version.
106 [3.2] Yes. Yes. The "Script" tag syntax, enabled by setting the tag-format to "semantics/1.0", defines the contents of tags to be ECMAScript. A Semantic Interpretation Script holds a string that is treated as the source text of a valid ES-CP Program.
107 [3.2] Yes. Yes. The "String Literal" tag syntax, enabled by setting the tag-format to "semantics/1.0-literals", defines the contents of tags to be strings.
108 [3.2] Yes. No. Within one grammar, it is not possible to mix the two tag syntaxes. All tags in one grammar must have the same tag-format. See also assertion 138.
110 [3.2] Yes. Yes. It is possible for externally referenced grammars to have a different tag-format to the parent grammar they are referenced from.
111 [3.2.2] Yes. Yes. 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 ES-CP.
112 [3.2.2] Yes. No. 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 var statement). Attempting to assign to an undeclared variable will result in a runtime error.
113 [3.2.3] Yes. Yes. 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 DoubleStringCharacters or the SingleStringCharacters production of ES 7.8.4.
114 [3.2.3] Yes. Yes. 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.
115 [4.2] Yes. Yes. There are no ordering constraints between SI Tags and other valid SRGS grammar header items.
116 [6.3] Yes. Yes. If any of the variables in the flat parse already exist, they are overwritten
117 [7] No. Yes. Object Type information and "DontEnum" properties are not serialized
118 [7.1] No. Yes. Simple ETLRV types generate XML fragment consisting of character data without any mark-up. The character data will be result of calling the ToString() on the ETLRV.
119 [7.1] No. Yes. Each property in the ETLRV becomes an XML element of that name.
120 [7.1] No. Yes. Simple scalar property values types (String, Number, Boolean, Null or Undefined) will generate XML character data content contained in the XML element as a result of calling ToString() on the property value.
121 [7.1] No. Yes. For complex property values (Object) each child property of this object becomes a child element, and the contents of these child elements are in turn processed.
122 [7.1] No. Yes. Indexed elements of an Array object (e.g. a[0], a[1]. etc.) become XML child elements with name 'item'. Each <item> element has an attribute named 'index', which is the index of the corresponding element in the array. In addition, the XML element containing the 'item's includes an attribute named 'length', whose value is given by the length property of the ECMAScript Array object.
123 [7.1] No. No. It is an error to transform an ECMAScript object into XML, that contains properties with names that are not allowed in XML.
124 [7.2] No. Yes. Properties specified in the _attributes object are rendered as XML attributes of the containing object.
125 [7.2] No. Yes. The value of _value is treated as character data content of the containing object or the value of an attribute if the containing object is a child of _attributes.
126 [7.3] No. Yes. When an object contains the _nsdecl property, the namespace declaration is attached to the resultant XML serialized element for this object.
127 [7.3] No. Yes. The _prefix property of _nsdecl indicates the namespace prefix and the _name property of _nsdecl indicates the corresponding namespace name (usually a URI reference).
128 [7.3] No. Yes. If the _prefix property is an empty string, the default namespace is declared.
129 [7.3] No. Yes. If both _prefix and _name are empty strings, the namespace declaration xmlns="" applies.
130 [7.3] No. Yes. When an Array object contains the _nsprefix property, the prefix also applies to the automatically generated <item> elements and length and index attributes.
131 [7.1] No. Yes. The values of properties of type String may contain special characters such as < and &, which could be erroneously treated as the start of markup by XML processors. An SI processor can use CDATA sections or character escaping to avoid this problem.
132 [7.1] No. Yes. Not indexed elements of an Array object, for instance the keys of an associative array (e.g. a["prop"]), are subject to the same transformation rules as the regular properties of an object.
133 [7.1] No. Yes. In a sparse array, only those elements which hold defined values will be serialized.
134 [3.3.2] Yes. Yes. Special Rule VOID can not be evaluated.
135 [3.3.2] Yes. Yes. Special Rule GARBAGE can not be evaluated.
136 [5] Yes. Yes. For a given parse, if there is no SI Tag attached to the expansion in the grammar rule and there are no rule references in the parse, the value for the text meta variable is automatically copied into the Rule Variable 'out' (which then becomes of type string). Applied to semantic scripts.
137 [5] Yes. Yes. 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 if there is at least one rule reference, the value of the Rule Variable of the last rule reference in the parse is automatically copied into the Rule Variable. Applied to semantic scripts.
138 [3.2] Yes. Yes. The two different possible values of the tag-format 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. Literals version. See also assertion 108.
139 [3.1] No. Yes. For every Rule Variable there are two associated variables named "starttime" and "endtime", of type Number, which hold the starting time and ending time of the utterance that is governed by the corresponding grammar rule.
140 [3.1] No. Yes. The starttime and endtime values must be an absolute timestamp in terms of the number of milliseconds since 1 January 1970 00:00:00 GMT.
141 [3.1] No. Yes. For any given Rule Variable, if both starttime and endtime values are not undefined, then the starttime value must not be greater than the endtime value.
142 [3.1] No. Yes. For any given Rule Variable, if the applicable starttime and endtime values are not undefined, then the starttime and the endtime value related to the corresponding grammar rule must not be smaller than the starttime value related to the referencing grammar rule.
143 [3.1] No. Yes. For any given Rule Variable, if the applicable starttime and endtime values are not undefined, then the starttime and the endtime value related to the corresponding grammar rule must not be greater than the endtime value related to the referencing grammar rule.
144 [3.3.3] No. Yes. The Rule Variable's starttime and endtime variables are identified by meta.rulename.starttime and meta.rulename.endtime, where rulename is the name of the Rule Variable.
145 [3.3.3] No. Yes. The starttime and endtime variables of the Rule Variable referred to by rules.latest() are identified by meta.latest().starttime and meta.latest().endtime.
146 [3.3.3] No. Yes. The starttime and endtime variables associated to the current grammar rule are identified by meta.current().starttime and meta.current().endtime.
147 [3.3.3] No. Yes. The starttime and endtime variables of the current grammar rule are read-only.
148 [6.3] Yes. Yes. Before the first tag in a flat parse is executed, the environment of a new scope is set up in the following way: rules.latest() returns undefined.
149 [6.3] Yes. Yes. Before the first tag in a flat parse is executed, the environment of a new scope is set up in the following way: meta.latest() returns undefined.
150 [6.3] No. Yes. 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: meta.rulename.starttime of the scope of the referencing rule, where rulename is the name of the referenced rule, is set to starting time value for the referenced rule.
151 [6.3] No. Yes. 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: meta.rulename.endtime of the scope of the referencing rule, where rulename is the name of the referenced rule, is set to ending time value for the referenced rule.
152 [6.3] No Yes. 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: meta.latest().starttime = meta.rulename.starttime (both variables are in the scope of the referencing rule).
153 [6.3] No. Yes. 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: meta.latest().endtime = meta.rulename.endtime (both variables are in the scope of the referencing rule).
154 [3.1] Yes. Yes. Processors that don't compute or don't have access to score values must return undefined as the score value.
155 [3.1] Yes. Yes. The starttime and endtime variables must be undefined if the SI processor does not have time information for the input or cannot process time information.

Appendices

Appendix A - Test assertion API definition

This appendix describes the framework employed for authoring SISR tests. Tests are written using Speech Recognition Grammar Specification (SRGS) grammars (XML Form) with embedded semantic scripts or semantic literals. The input utterance and the corresponding intended semantic result output are contained in metadata (described below). A fixed number of predefined tokens are used in the SRGS grammar to facilitate automatic translation to a different speech recognition language or to DTMF type grammars.

A.1 Test metadata

A child element of <metadata> called <test-data> is employed to hold the prescribed input utterance and the corresponding desired semantic result output.

The <test-data> element has a required attribute called input which contains the input utterance used to match against the grammar. The utterance is constrained to use only the following tokens (in any order and with any multiplicity):

The semantic result obtained from matching the utterance to the grammar and subsequently processing the SISR <tag>s is represented either as an ECMAScript Object Initialiser (see Section 11.1.5 of ECMA-262) contained in the output attribute of <test-data> or as the XML Serialized equivalent (see Section 7.0 of SISR) contained in the child content of <test-data>.

The <metadata> element only contains one <test-data> element (i.e. there is only one input-output pair for each test). The <test-data> and children (if any) employ the namespace http://www.w3.org/2006/01/sisr-conformance. The corresponding XML schema is given below.

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema targetNamespace="http://www.w3.org/2006/01/sisr-conformance"
            xmlns="http://www.w3.org/2006/01/sisr-conformance"
            xmlns:xsd="http://www.w3.org/2001/XMLSchema"
            elementFormDefault="qualified">

    <xsd:simpleType name="GrammarToken.datatype">
        <xsd:restriction base="xsd:token">
            <xsd:enumeration value="vienna"/>
            <xsd:enumeration value="redmond"/>
            <xsd:enumeration value="boston"/>
            <xsd:enumeration value="budapest"/>
            <xsd:enumeration value="paris"/>
        </xsd:restriction>
    </xsd:simpleType>

    <xsd:simpleType name="GrammarTokens.datatype">
        <xsd:list itemType="GrammarToken.datatype"/>
    </xsd:simpleType>

    <xsd:element name="test-data">
        <xsd:complexType mixed="true">
            <xsd:sequence minOccurs="0" maxOccurs="unbounded">
                <xsd:any processContents="skip"/>
            </xsd:sequence>
            <xsd:attribute name="input" type="GrammarTokens.datatype" use="required"/>
            <xsd:attribute name="output" type="xsd:string"/>
        </xsd:complexType>
    </xsd:element>

</xsd:schema>

A.2 Test examples

This section illustrates example tests. For clarity, the schema locations have been omitted

Example 1

The following example demonstrates the usual case of the output given as an ECMAScript Object Initialiser. 

<?xml version="1.0" encoding="UTF-8"?>
<grammar version="1.0"
         xml:lang="en-IE"
         root="top"
         tag-format="semantics/1.0"
         xmlns="http://www.w3.org/2001/06/grammar">

    <metadata>
        <test-data input="boston"
                   output="{ answer: 7 }"
                   xmlns="http://www.w3.org/2006/01/sisr-conformance"/>
    </metadata>

    <rule id="top" scope="public">
        boston <tag>out.answer=1+2*3</tag>
    </rule>

</grammar>

Example 2

The following example demonstrates the output given in the XML Serialization representation. 

<?xml version="1.0" encoding="UTF-8"?>
<grammar version="1.0"
         xml:lang="en-IE"
         root="top"
         tag-format="semantics/1.0"
         xmlns="http://www.w3.org/2001/06/grammar">

    <metadata>
        <test-data input="boston"
                   xmlns="http://www.w3.org/2006/01/sisr-conformance">
            <answer>7</answer>
        </test-data>
    </metadata>

    <rule id="top" scope="public">
        boston <tag>out.answer=1+2*3</tag>
    </rule>

</grammar>

Appendix B - Acknowledgements

The SISR 1.0 Implementation Report includes 119 assertions and corresponding tests. The Voice Browser Working Group would like to further acknowledge the contributions of several individuals: