Copyright © 2006 W3C® (MIT , ERCIM , Keio), All Rights Reserved. W3C liability, trademark, document use, and software licensing rules apply.
This document details the responses made by the Voice Browser Working Group to issues raised during the Last Call (beginning 8 November 2004 and ending 5 December 2004) review of Semantic Interpretation for Speech Recognition (SISR) Version 1.0. Comments were provided by Voice Browser Working Group members, other W3C Working Groups, and the public via the www-voice-request@w3.org (archive) mailing list.
This document of the W3C's Voice Browser Working Group describes the disposition of comments as of 11th January 2006 on the Last Call Working Draft of Semantic Interpretation for Speech Recognition (SISR) Version 1.0. It may be updated, replaced or rendered obsolete by other W3C documents at any time.
For background on this work, please see the Voice Browser Activity Statement.
This document describes the disposition of comments in relation to Semantic Interpretation for Speech Recognition (SISR) Version 1.0 (http://www.w3.org/TR/2004/WD-semantic-interpretation-20041108/). Each issue is described by the name of the commentator, a description of the issue, and either the resolution or the reason that the issue was not resolved.
The full set of issues raised for the Semantic Interpretation for Speech Recognition (SISR) Version 1.0 since November 2004, their resolution and in most cases the reasoning behind the resolution are available from http://www.w3.org/TR/2006/CR-semantic-interpretation-20060111/sisr10-cr.html [W3C Members Only]. This document provides the analysis of the issues that were submitted and resolved as part of the Last Call Review. It includes issues that were submitted outside the official review period, up to 20th February 2006.
Notation: Each original comment is tracked by a change request designator, SISR-DOC. Each point within that original comment is identified by a point number. For example, SISR-DOC1.2 is the second point in the first change request for the specification.
| Item | Commentator | Nature | Disposition |
|---|---|---|---|
| SISR-DOC1.1 | Paolo Baggia (VBWG Group) | Request to Change Existing Features | Accepted |
| SISR-DOC2.1 | Charles McCathieNevile, Dominique Hazaël-Massieux (QA Group) | Clarifications, Typographical, and Other Editorial | Accepted |
| SISR-DOC2.2 | Charles McCathieNevile, Dominique Hazaël-Massieux (QA Group) | Clarifications, Typographical, and Other Editorial | Accepted |
| SISR-DOC2.3 | Charles McCathieNevile, Dominique Hazaël-Massieux (QA Group) | Clarifications, Typographical, and Other Editorial | Accepted |
| SISR-DOC2.4 | Charles McCathieNevile, Dominique Hazaël-Massieux (QA Group) | Clarifications, Typographical, and Other Editorial | Rejected |
| SISR-DOC2.5 | Charles McCathieNevile, Dominique Hazaël-Massieux (QA Group) | Clarifications, Typographical, and Other Editorial | Rejected |
| SISR-DOC2.6 | Charles McCathieNevile, Dominique Hazaël-Massieux (QA Group) | Clarifications, Typographical, and Other Editorial | Rejected |
| SISR-DOC6.1 | Michael Johnston, Debbie Dahl (MMI Group) | Clarifications, Typographical, and Other Editorial | Accepted |
| SISR-DOC6.2 | Michael Johnston, Debbie Dahl (MMI Group) | Clarifications, Typographical, and Other Editorial | Accepted |
| SISR-DOC6.3 | Michael Johnston, Debbie Dahl (MMI Group) | Feature Requests | Accepted |
From Charles McCathieNevile:
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). The full details are available at http://www.w3.org/2004/12/cmn-si-review. This specific issue:
- Provide wording for conformance claims
- Provide an Implementation Conformance Statement proforma
- Require an Implementation Conformance Statement as part of valid conformance claims
Resolution: Accepted
The group discussed this request and concluded as follows:
Email Trail:
From Charles McCathieNevile:
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). The full details are available at http://www.w3.org/2004/12/cmn-si-review. This specific issue:
There are examples and use cases, but no graphics, which would have been a nice thing to explain some points.
Resolution: Accepted
The group examined the specification and explored what sections would benefit from further clarification by means of graphics or examples. The group did not find places that we believe would be helped with more graphics but did discuss some ways of improving or adding examples; in particular an example to show more use cases of semantic interpretation scripts for aggregating information and for computing information was added, in addition to a note about how to use namespaces to utilize the XML Serialization in connection with W3C EMMA.
Email Trail:
From Charles McCathieNevile:
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). The full details are available at http://www.w3.org/2004/12/cmn-si-review. This specific issue:
Define the terms used in the specification.
Resolution: Accepted
The group discussed this and decided to a add a glossary to the specification.
Email Trail:
From Charles McCathieNevile:
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). The full details are available at http://www.w3.org/2004/12/cmn-si-review. This specific issue:
Address extensibility: It is noted as something that is likely to happen, in the section on conformance. But it is not actually addressed.
Resolution: Rejected
The group discussed this issue and acknowledged that a limitation of the specification is that it is not possible to have forward-compatible SI processors but after careful review and discussion, the group concluded that this is not a serious limitation. Since the contents of <tag>s are ECMAScript code, it is difficult to predict how a semantics/1.x would function and therefore make forward-compatibility tenable. The group has, instead, favoured the approach of clean designation and separation of SI formats employed within grammars.
Email Trail:
From Charles McCathieNevile:
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). The full details are available at http://www.w3.org/2004/12/cmn-si-review. This specific issue:
Write sample code or tests: This is sufficient for a last call document, but this work should be done to allow a reasonable demonstration of interoperability at any more advanced stage in the specifications development.
Resolution: Rejected
Similar as to SISR-DOC2.2, the group examined the specification to check for additional need for examples - see SISR-DOC2.2 for resulting additions.
Email Trail:
From Charles McCathieNevile:
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). The full details are available at http://www.w3.org/2004/12/cmn-si-review. This specific issue:
Good Practice: Write test assertions. Are these test assertions linked anywhere from the specification? Are they considered normative? Is there a mapping between these test assertions and the specification?
Resolution: Rejected
The group has generated a set of test assertions as part of the Implementation Report Plan designed to test and demonstrate interoperability. Each test is marked as required or optional. Each test is linked to the specification. While the tests are not normative, the group does (according to W3C process) require two interoperable implementations of each feature and one implementation of each optional feature.
Email Trail:
From Michael Johnston, Debbie Dahl:
It would be good if we could clarify the role of EMMA in standardizing the containers and annotation for semantic representation rather than the semantic representation of user utterances itself.
Resolution: Accepted
Changed last sentence in abstract:
"The W3C Multimodal Interaction Activity is defining a data format
(EMMA) for representing the information contained in user utterances"
to
"The W3C Multimodal Interaction Activity is defining an XML data format
(EMMA) for containing and annotating the information in user utterances"
Changed second to last paragraph in section 1.1 to:
"The W3C Multimodal Interaction Activity is defining an XML data format
(EMMA) for containing and annotating the information in user utterances"
EMMA reference updated in bibliography.
Other miscellaneous typos corrected.
Email Trail:
From Michael Johnston, Debbie Dahl:
Informative section on how to generate emma namespace elements in SI output:
- Informative section on the general use of SI in EMMA
- Example for emma:hook
- Example for emma:tokens
Resolution: Accepted
The group discussed this issue and had some discussion on this with EMMA subgroup members. The group's position is that it believes examples on EMMA and how to generate that with other processors, belong to the EMMA specification (there is already such an example in the EMMA specification). The group concluded to not add the suggested examples to the SI specification but agreed to add a note about usage of the namespace feature for emma:hook and emma:tokens to Section 7.3. A pointer to the relevant Appendix C in EMMA was also added.
Email Trail:
None.
From Paolo Baggia:
The current version of the LCWD allows to propagate different values for the two syntaxes. This may happen if the grammar writer assigns different values to $ or 'out' variables. An easy example was already shown by Dave Burke of assigning a scalar value to either $ or 'out'. This behaviour implies that a grammar writer needs to know which syntax is used in an external grammar reference. This is very dangerous, it may generate misunderstanding and possibly to undermine the SI formalism.
Resolution: Accepted
The working group discussed this request in detail, and concluded to accept solution 1. More precisely the group decided to fully remove the $ syntax from the specification. This greatly simplifies authoring (otherwise there would be two grammar formats and two SI formats leading to four permutations to express the same thing). Furthermore, the overloading of $ is removed (a source of confusion for authors). In addition, removal of the $ syntax avoids erroneous behaviours that would otherwise result from having a dual syntax. Finally, it also simplifies implementation.
Email Trail:
From Michael Johnston, Debbie Dahl:
Informative section on how to generate emma namespace elements in SI output: Adding temporal metadata to SI/SRGS
Resolution: Accepted
The group had several discussions on this and thanks the EMMA group also for the participation in and contribution to that discussion. The group accepted to add "starttime" and "endtime" information associated with Rule Variables.
Email Trail: