The ATAG Last call draft seems to conform to all but one of the requirements - that of clarifying the deprecation of some features, and the group seems to recognise already that this needs to be done. In addition, most of the good practices are implemented too.
The major caveat is that since the specification relies on a non-free specification from ISO, to which I don't have access, I have not been able to check parts related to that. I think that at the least a much more detailed treatment of what is in that specification, and how it should be used (with examples) is important.
| 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 | |
| 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. | Yes | |
| Good Practice : Provide an Implementation Conformance Statement proforma. | Yes | |
| Good Practice : Require an Implementation Conformance Statement as part of valid conformance claims. | Yes | |
| 2. Setting up Groundrules | ||
| 2.1. Scope | ||
| Requirement : Define the scope. | Yes | |
| Good Practice : Provide examples, use cases, and graphics. | Yes | There are examples, use cases, and graphics in the accompanying Note "Techniques for ..." |
| 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 | In particular it is hard to know what review has been done for ISO 16071, since it is not freely available and I don't have access to a copy. |
| 3. terms | ||
| 3.1 Define terms | ||
| Requirement : Define the terms used. | Yes | |
| Requirement : Create conformance labels | Yes | |
| Good Practice : define unfamiliar terms inline, group at the end | Partial (No) | Some things are defined inline, some in the glossary at the end, some in both ways. |
| Good Practice : Use terms already defined | Cannot tell | Terms seem to be used with their normal meanings. |
| 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 | Success criteria are very nice. |
| 4. Managing Variability | ||
| 4.1 Subdivide | ||
| Good Practice : Create subdivisions of the technology when warranted. | Yes | To the extent that some checkpoints only apply to some kinds of tools. More substantially addressed in the techniques document where it is more relevant |
| 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 | There is a simple cumulative model. |
| Good Practice : If the technology is profiled, define rules for creating new profiles. | Not Applicable | |
| 4.2 Optionality and Options | ||
| Good Practice : Make sure there is a need for the optional feature. | Yes | The three levels of conformance effectively provide optional features. There is a strong demand for some graded scale, and it seems clearly explained and justified in the Spec. |
| 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. | Yes | The structure of the specification and the related techniques document means that maximum flexibility is allowed in meeting functional requirements, while guidance is provided in areas where the working group feels that there is currently only one practical way to meet a checkpoint. |
| Good Practice : If extensibility is allowed, define an extension mechanism. | Not Applicable | |
| Good Practice : Warn implementers to create extensions that do not interfere with conformance. | Not Applicable | |
| Good Practice : Define error handling for unknown extensions. | Not Applicable | |
| 4.4 Deprecation | ||
| Requirement : Identify deprecated features. | No | The Status of the Document says the group will publish an analysis of the differences if there are any, before the last call. |
| Requirement : Define how deprecated feature is handled by each class of product. | Cannot Tell | |
| Good Practice : Explain how to avoid using a deprecated feature. | Yes | In so far as there are Techniques in the related techniques note... |
| Good Practice : Identify obsolete features. | No | See the requirement 4.4A |
| 4.5 Error Handling | ||
| Good Practice : Define an error handling mechanism. | Not Applicable | |
| 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. | Partial | There are some examples in the ATAG techniques note. This work is ongoing |
| Good Practice : Write Test Assertions. | Yes | There are success criteria for each checkpoint. |
| Good Practice : Use formal languages and define which from prose and formal languages has priority. | N/A | As far as I can tell |