W3C Specification Guidelines (checklist)

2.1 Specifying Conformance

[ ] 2.1.1 A conformance clause is essential.
[ ] 2.1.2 Specify how to make conformance claims.

2.2 Setting Up Ground Rules

[ ] 2.2.1 Scope
[ ] 2.2.2 What needs to conform?
[ ] 2.2.3 Normative (and Non-Normative) References

2.3 Defining and Using Terminology

[ ] 2.3.1 Define terms.
[ ] 2.3.2 What is mandatory?

2.4 Managing Variability

[ ] 2.4.1 Subdivide.
[ ] 2.4.2 Optionality and Options
[ ] 2.4.3 Extensibility and Extensions
[ ] 2.4.4 Deprecation
[ ] 2.4.5 Error Handling
1. Beyond Conformance
[ ] 3.1 Define an internal publication and review process.
[ ] 3.2 Do a systematic and thorough review.
[ ] 3.3 Accessibility, Internationalization, and Device Independence Considerations

List of Requirements:

[ ] Requirement 1: Include a conformance clause.
[ ] Requirement 2: Define the scope.
[ ] Requirement 3: Identify who and/or what will implement the specification.
[ ] Requirement 4: Make a list of normative references.
[ ] Requirement 5: Define the terms used in the normative parts of the specification.
[ ] Requirement 6: Create conformance labels for each part of the conformance model.
[ ] Requirement 7: Use a consistent style for conformance requirements and explain how to distinguish them.
[ ] Requirement 8: Indicate which conformance requirements are mandatory, which are recommended, and which are optional.
[ ] Requirement 9: If the technology is subdivided, then indicate which subdivisions are mandatory for conformance.
[ ] Requirement 10: If the technology is subdivided, then address subdivision constraints.
[ ] Requirement 11: Address extensibility.
[ ] Requirement 12: Identify deprecated features.
[ ] Requirement 13: Define how each class of products handles each deprecated feature.

List of Good Practices:

[ ] Good Practice 1: Define the specification's conformance model in the conformance clause.
[ ] Good Practice 2: Specify in the conformance clause how to distinguish normative from informative content.
[ ] Good Practice 3: Provide the wording for conformance claims.
[ ] Good Practice 4: Provide an Implementation Conformance Statement Pro Forma.
[ ] Good Practice 5: Require an Implementation Conformance Statement as part of conformance claims.
[ ] Good Practice 6: Provide examples, use cases, and graphics.
[ ] Good Practice 7: Write sample code or tests.
[ ] Good Practice 8: When imposing requirements by normative references, address conformance dependencies.
[ ] Good Practice 9: Define unfamiliar terms in-line and consolidate the definitions in a glossary section.
[ ] Good Practice 10: Use terms already defined without changing their definition.
[ ] Good Practice 11: Use formal languages when possible.
[ ] Good Practice 12: Write test assertions.
[ ] Good Practice 13: Create subdivisions of the technology when warranted.
[ ] Good Practice 14: If the technology is profiled, define rules for creating new profiles.
[ ] Good Practice 15: Use optional features as warranted.
[ ] Good Practice 16: Clearly identify optional features.
[ ] Good Practice 17: Indicate any limitations or constraints on optional features.
[ ] Good Practice 18: If extensibility is allowed, define an extension mechanism.
[ ] Good Practice 19: Warn extension creators to create extensions that do not interfere with conformance.
[ ] Good Practice 20: Define error-handling for unknown extensions.
[ ] Good Practice 21: Explain how to avoid using a deprecated feature.
[ ] Good Practice 22: Identify obsolete features.
[ ] Good Practice 23: Define an error handling mechanism.

QA Framework: Specification Guidelines W3C Recommendation 17 August 2005 http://www.w3.org/TR/qaframe-spec/

OpenGovLD / specs

W3C Specification Guidelines (checklist) #47