RE: [si] (SISR-DOC2) QA Review of Semantic Interpretation last ca ll draft

Hi Luc,

Thanks for considering the QA comments that Charles sent back in
December. Charles has left the W3C Team since then, so I'm taking the
liberty to respond in his stead on these comments.

Le mardi 17 mai 2005 à 20:00 -0400, Van Tichelen, Luc a écrit :
> SISR-DOC2.1: Related to 1.2 Specify how to make 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). 

This sounds great.

> SISR-DOC2.2: On 2.1. Good Practice : Provide examples, use cases, and
> graphics.
> You commented "There are examples and use cases, but no graphics, which
> would have been a nice thing to explain some points". 
> 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.
> SISR-DOC2.5: 5. Write sample code or tests
> 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.

Ok; I can't tell for sure where Charles thought more examples would have
helped, but I trust your judgment on this.

> SISR-DOC2.3: On 3.1. Requirement : Define the terms used
> The group discussed this and decided to a add a glossary to the
> specification. 

Perfect! Please make sure to follow the convention to put the said
glossary into a:
<dl class="glossary">
<dt>term</dt>
<dd>definition</dd>
<dt>other term</dt>
<dd>other definition</dd>
</dl>

(unless you're using XMLSpec which already does the right thing). Doing
so makes it much easier to include the said glossary into the central
W3C Glossary once the document reaches Rec status
http://www.w3.org/2003/glossary/


> SISR-DOC2.4: On 4.3. Requirement : Address Extensibility
> Your review indicates that specification only partially addresses
> extensibility: "It is noted as something that is likely to happen, in the
> section on conformance. But it is not actually addressed.". Also, 2 good
> practices around this are not followed.
> 
> 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.

Agreed.

> 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). 

OK; I agree that this case is border-line in terms of being considered
as an extension or not.

> 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. 

OK; I guess you could document this in a sub-section called
Extensibility in the Conformance section, and this would both address
Charles's original comment and make the Working Group intention clearer.

Note that with that scheme, you make it impossible to have
forward-compatible processors; for instance, if you were to design SI
Tags v1.1 with only a few optional additional tags, SIT processors of
v1.0 could not process the 1.1 documents. XML has been bitten by this
recently.

> SISR-DOC2.6: 5. Write test assertions
> Also rated OK but minimal. 
> 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. 

This is what I think is asked by SpecGL; are these test assertions
linked anywhere from the specification? Are they considered normative?
Is there a mapping between these test assertions and the specification?

Dom
-- 
Dominique Hazaël-Massieux - http://www.w3.org/People/Dom/
W3C/ERCIM
mailto:dom@w3.org