The Specification does not conform to the QA Specification Guidelines, because it does not conform to requirements 3.1 A or B, nor to requirement 4.4 A. There are also some good practices that the document should have implemented better. Meeting the first two of the missing requirements should be essentially an editorial question, but meeting the requirement to address extensibility may require more substantive work on the part of the Working Group.
All three requirements should be met, since the first two will aid developers to produce interoperable implementations, and the third is extremely important given the working groups stated belief (presumably well-founded on their own implementation experience) that extensions will be developed.
The good practices in sections 1.2 (providing more guidance about how to make a conformance claim), 3.1 (defining terms clearly) and 4.3 (addressing extensibility) should also be met.
| Guidelines | Y / N | Comments |
|---|---|---|
| 1 Specifying Conformance | ||
| 1.1 A conformance clause is essential | ||
| Requirement : Include a conformance clause. | Yes | |
| Good Practice : Define the specification's conformance model in the conformance clause. | Yes | for processors and for documents.
Section 2 being called normative references and conformance, when it is another section that covers conformance, could be cleaned up a little. |
| Good Practice : Specify in the conformance clause how to distinguish normative from informative content. | Yes | |
| 1.2 Specify how to make conformance claims | ||
| Good Practice : Provide the wording for conformance claims. | No | |
| Good Practice : Provide an Implementation Conformance Statement proforma. | No | |
| Good Practice : Require an Implementation Conformance Statement as part of valid conformance claims. | No | |
| 2. Setting up Groundrules | ||
| 2.1. Scope | ||
| Requirement : Define the scope. | Yes | Describes stuff beyond the scope too - nice. |
| Good Practice : Provide examples, use cases, and graphics. | Partial (No) | There are examples and use cases, but no graphics, which would have been a nice thing to explain some points |
| 2.2 What needs to conform | ||
| Requirement : Identify who or what will implement the specification. | Yes | |
| 2.3 Normative (and non-normative) references | ||
| Requirement : Make a list of normative references. | Yes | |
| Good Practice : Do systematic reviews of normative references and their implications. | Cannot Tell | |
| 3. terms | ||
| 3.1 Define terms | ||
| Requirement : Define the terms used. | No | No glossary. |
| Requirement : Create conformance labels | Yes | |
| Good Practice : define unfamiliar terms inline, group at the end | Partial (No) | There are some practical explanations, but no glossary. |
| Good Practice : Use terms already defined | Cannot tell | There doesn't seem to be much special use of terms. |
| 3.2 What is mandatory to conform | ||
| Requirement : Use consistent style for things required | Yes | I think - RFC 2119. |
| Requirement : Indicate which requirements are mandatory, which are optional, ... | Yes | But it isn't lovely to tease it out. I don't think they are clearly listed in a single place. |
| 4. Managing Variability | ||
| 4.1 Subdivide | ||
| Good Practice : Create subdivisions of the technology when warranted. | Yes | This is in fact a subdivision of the VoiceXML family of technology. |
| Requirement : If the technology is subdivided, then indicate which subdivisions are mandatory for conformance. | Yes | |
| Requirement : If the technology is subdivided, then address subdivision constraints. | Yes | |
| Good Practice : If the technology is profiled, define rules for creating new profiles. | Not Applicable | There doesn't seem to be any possibility to define new profiles. |
| 4.2 Optionality and Options | ||
| Good Practice : Make sure there is a need for the optional feature. | Cannot Tell | Cannot tell if the option to use ABNF or XML is justified. It just seems to be claimed by the group. |
| Good Practice : Clearly identify optional features. | Yes | |
| Good Practice : Indicate any limitations or constraints on optional features. | Yes | |
| 4.3 Extensibility and Extensions | ||
| Requirement : Address Extensibility. | Partial (No) | It is noted as something that is likely to happen, in the section on conformance. But it is not actually addressed. |
| Good Practice : If extensibility is allowed, define an extension mechanism. | No | |
| Good Practice : Warn implementers to create extensions that do not interfere with conformance. | No | |
| Good Practice : Define error handling for unknown extensions. | Yes | |
| 4.4 Deprecation | ||
| Requirement : Identify deprecated features. | N/A | |
| Requirement : Define how deprecated feature is handled by each class of product. | N/A | |
| Good Practice : Explain how to avoid using a deprecated feature. | N/A | |
| Good Practice : Identify obsolete features. | N/A | |
| 4.5 Error Handling | ||
| Good Practice : Define an error handling mechanism. | Yes | |
| 5. Do Quality Control | ||
| Good Practice : Define an internal publication and review process. | Yes | W3C process, which seems to have been followed pretty well. |
| Good Practice : Do a systematic and thorough review. | Yes | Apparently |
| Good Practice : Write sample code or tests. | Yes (minimal) | Only the examples in the spec. 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. |
| Good Practice : Write Test Assertions. | Yes (minimal) | Only the examples in the spec. 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 |
| Good Practice : Use formal languages and define which from prose and formal languages has priority. | Yes | As far as I can tell |