- From: Van Tichelen, Luc <Luc.VanTichelen@scansoft.com>
- Date: Tue, 17 May 2005 20:00:22 -0400
- To: Charles McCathieNevile <charles@w3.org>, www-qa@w3.org
- Cc: www-voice@w3.org
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 00:00:34 UTC