• Solution 1:
  Eliminate one of the two syntaxes, either '$' or 'out'
• Solution 2:
  • - Comma 1:
    The spec should clearly say that only one syntax MUST be used in a grammar document.
  • - Comma 2:
    The spec should enforce to generate a fatal error if the result of a rule is inconsistent. The allowable cases are the following:
    • - '$' and 'out' have the same value
    • - '$' has a value and 'out' has the initialization value
    • - 'out' has a value and '$' has the initialization value
    • - in all the other cases the SI processor must generate a fatal error
  • - Comma 3:
    The value propagated for a referenced rule MUST be the same for '$rulename' and 'rules.rulename'
  Those three conditions should allow to propagate a single value and to enforce a consistent use in a grammar file.

The working group discussed this request in detail, and concluded to accept what you proposed as solution 1. More precisely the group decided to fully remove the $ syntax from the specification.

The working group discussed this request and concluded to leave the spec as is on this point. You already indicated during the working group meetings that you accept this resolution.

The working group discussed this request as well, and similarly concluded to leave the spec as is on this point. You already indicated during the working group meetings that you accept this resolution.

The working group discussed this request and agreed it is useful to clarify. In trying to insert the edit, I noticed that there is already the following sentence in section 6.3: "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 4.2.). " This sentence defines the execution and visibility of the tags in the grammar header in relation to the tags in the flat parse list. It indeed doesn't express the tags in the header in a flat parse list (or logical parse), as these tags do not correspond to matching a rule. Could the above mentioned sentence be sufficient clarification or do you believe there is a need for additional clarification?

Thanks for spotting these typos. I will process these in editing the draft.
20050727: edited in draft -> released.

• Provide wording for conformance claims
• Provide an Implementation Conformance Statement proforma
• Require an Implementation Conformance Statement as part of valid conformance claims

The group has discussed this request and concluded as follows:

• We will provide a template for wording of conformance claim for conforming grammars and conforming processors, along the following example: This document conforms to W3C's "Semantic Interpretation for Speech Recognition", available at http://www.w3.org/TR/semantic-interpretation-YYYYMMDD, semantics/x.y or semantic/x.y-literals where YYYYMMDD is the publication date of the specification and x and y refer to the version number of the tag-format.
• There is really only one area of optionality in the specification: XML Serialization. Rather than providing a questionnaire or form, we will provide a phrase like "supporting XML Serialization" that can be optionally added to the conformance wording for a conforming processor (this optional feature only applies to processors, not documents).

The group has examined the specification and explored what sections would benefit from further clarification by means of graphics or examples. We did not find places that we believe would be helped with more graphics. We did discuss some ways of improving or adding examples; in particular we will be adding an example to show more use cases of semantic interpretation scripts for aggregating information and for computing information, and we will be adding a note about how to use namespaces to utilize the XML Serialization in connection with W3C EMMA.

The group discussed this and decided to a add a glossary to the specification.

The group discussed this and had some discussion with Dominique Hazaël-Massieux, but is not clear yet on the resolution.
Indeed in section 9.3 http://www.w3.org/TR/2004/WD-semantic-interpretation-20041108/#SI9.3. the spec lists a number of ways in which it is expected that documents could be non-conforming:
1. Non-conforming document by developer error (or error in automatic document generation).
2. Not conforming by use of a proprietary semantic interpretation syntax in the grammar tags.
3. Not conforming by use of proprietary extensions to SI Tags.
Case 1. is not about extension but errors, and so probably doesn't need further discussion.
Case 2. is about the use of a different syntax than the one defined by SI (as tag-format="semantics/1.0" or "semantics/1.0-literals". This is probably better classified as an "alternative" to SI rather than as an "extension". The Speech Recognition Grammar Specification http://www.w3.org/TR/speech-grammar/ does not restrict grammars to using the syntax defined by Semantic Interpretation, other than that it can not use the reserved tag-format semantics/x.y for a syntax that is not conforming to what is defined in Semantic Interpretation. (see http://www.w3.org/TR/speech-grammar/#S4.8 ). An SI processor that is processing a document with SI tags declared as semantics/x.y but with different syntax being used, or with a tag-format specifying another format than semantics/x.y, is thus processing a non-conforming SI document and should handle that as indicated. This was listed as an expected case of non-conformance because there are already several commercial implementations of speech grammar processors using deviating syntax and/or tag-format (and by consequence, there are also several documents with such deviating syntax or tag-format).
Case 3. is truly about extensions. SI Tags can be extended provided that the format is not declared as semantics/x.y. This means about the same as stating that the format is not SI tags, and therefore ensures that extensions are not confused with the conforming SI format but are instead indicated as different formats. When the format is declared as semantics/x.y, the SI tags and their processing must conform to the requirements in section 9.2 and 9.3, thereby ensuring interoperability. Interoperability of extended formats can be realized when processors also understand and process the tag-format commonly associated with the extended format.
I believe from the above, it is more accurate to state that there is no extensibility allowed; but a mechanism (the tag-format) is provided to allow extensions or deviating syntaxes to be used while clearly indicating these as being different from the conforming documents. The specification does not define how such extensions or deviating syntaxes should be processed, other than that a conforming processor must report the non-conformance to the hosting environment.

You currently rated this as a OK but minimal. Similar as to SISR-DOC2.2, the group has examined the specification to check for additional need for examples; see SISR-DOC2.2 for additions planned.

The group discussed this and believes no further test assertions are needed to be added to the specification. The group is developing test assertions for the purpose of the implementation report, and these tests are indeed designed to test and demonstrate interoperability.

• about EMMA description, provides suggested wording
• typo's

• informative section on the general use of SI in EMMA
• Example for emma:hook
• Example for emma:tokens

• Those that use object aggregations of semantically related information
• Those that perform intra-grammar computations