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

Dear Charles and QA Working Group,

Thanks for your review of the Semantic Interpretation LCWD. For reference
the working group is tracking this review as SISR-DOC2, subdivided as
annotated below.
The working group has addressed and discussed all comments; the resulting
suggested actions are as indicated below. 
If you are unsatisfied by the resolution, please let us know with a
suggestion for a resolution that would be more satisfactory. If you are
satisfied by the resolutions, please simply reply stating so. 

Below I have grouped and listed the comments on requirements or good
practices for which you indicated (see
http://www.w3.org/2004/12/cmn-si-review) that the specification is currently
not conforming.  

SISR-DOC2.1: Related to 1.2 Specify how to make conformance claims 

Not conforming to following good practices:
* 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). 



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.3: On 3.1. Requirement : Define the terms used
The group discussed this and decided to a add a glossary to the
specification. 



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



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.



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. 




Note: You also listed a comment with 4.2 Optionality and Options: "Cannot
tell if the option to use ABNF or XML is justified. It just seems to be
claimed by the group.".
I believe this is not related to Semantic Interpretation but to the Speech
Recognition Grammar Specification (http://www.w3.org/TR/speech-grammar/).
Semantic Interpretation is not defining ABNF nor XML, it is defining the tag
contents used in both the ABNF and XML formats defined by Speech Recognition
Grammar Specification. From that perspective, ABNF and XML are not optional.


Kind Regards,

Luc Van Tichelen
Semantic Interpretation sub-group lead
W3C Voice Browser Working Group 
_______________________________________________________

SpeechWorks solutions from ScanSoft. Inspired Applications, Exceptional
Results.

Luc Van Tichelen
Director Embedded Solutions, SpeechWorks Division
ScanSoft, Inc.
p: +32 9 239 8000
f: +32 9 239 8001
www.scansoft.com 

-----Original Message-----
From: Charles McCathieNevile [mailto:charles@w3.org] 
Sent: 16 December 2004 16:02
To: www-voice@w3.org; www-qa@w3.org
Subject: QA Review of Semantic Interpretation last call draft


Hi folks,

I have done a review of the conformance of the Semantic Interpretation spec
last call draft (November 8) to the QA Framework's Specification Guidelines
(last call draft, November 22).

In rough summary:

Generally the document came out pretty well. It is quite close to conforming
to the draft specGL already, which is nice. There are a couple of
requirements from SpecGL that I think the Semantic Interpretation spec
should
meet but doesn't - two are editorial to do with more use of glossaries, and
one is probably more substantive and deals with the lack of any exlanation
of
how to address extensibility. Since the specification itself notes that the
working group expects the spec to be extended (which is useful and valuable
information) this seems a real issue to me.

The full details are available at http://www.w3.org/2004/12/cmn-si-review

I will maintain that document to track the results of any discussion or
review of my review.

Best regards

Charles McCN

--
Charles McCathieNevile             http://www.w3.org/People/Charles
tel: +61 409 134 136                 fax(france): +33 4 92 38 78 22
Post:    21 Mitchell street, FOOTSCRAY Vic 3011, Australia    or
 W3C, 2004 Route des Lucioles, 06902 Sophia Antipolis Cedex, France

Received on Wednesday, 18 May 2005 07:50:43 UTC