Reviewed by: [fill in reviewer/author name(s)]
Date completed: [fill in the date you finished]
DO NOT SEND THIS TO THE QA MAILING-LIST, send it to dom@w3.org
[Required: for SpecGL review, link to the document you reviewed.]
[Required: Overview and summary information, see examples in the review matrix, for what to put here for your specific Guideline type (Ops, Spec, Test).]
Guideline 1. Define user scenarios.
[...Required: per-Guideline summary/overview verbiage goes here...]
1.1 Define the scope of the specification. [Priority 1]
1.2 Include Use Cases. [Priority 2]
1.3 Include examples. [Priority 1]
1.4 Include an interpretation section. [Priority 2]
Guideline 2. Identify what needs to conform and how.
[...Required: per-Guideline summary/overview verbiage goes here...]
2.1 Identify all classes of product. [Priority 1]
2.2 For each class of product, define the conformance requirements. [Priority 1]
2.3 For each class of product, indicate minimal support requirements. [Priority 3]
2.4 Identify which of the categories of object are specified in the document as a whole. [Priority 3]
Guideline 3. Address the use of profiles to divide the specification.
[...Required: per-Guideline summary/overview verbiage goes here...]
3.1 Choose whether or not to have profiles. [Priority 1]
3.2 Include a table of contents entry. [Priority 1]
3.3 If profiles are chosen, indicate whether or not their use is mandatory for conformance. [Priority 1]
3.4 If profiles are chosen, define any minimal requirements. [Priority 2]
3.5 If profiles are chosen, define their relationships and interaction with other dimensions of variability. [Priority 2]
3.6 [@@new ckpt] If profiles are chosen, address rules for profiles. [Priority 2]
Guideline 4. Address the use of modules to divide the specification.
[...Required: per-Guideline summary/overview verbiage goes here...]
4.1 Choose whether or not to have modules. [Priority 1]
4.2 Include a table of contents entry. [Priority 1]
4.3 If modules are chosen, indicate any mandatory conditions or constraints on their usage. [Priority 1]
4.4 If modules are chosen, define their relationships and interaction with other dimensions of variability. [Priority 2]
Guideline 5. Specify conformance policy.
[...Required: per-Guideline summary/overview verbiage goes here...]
5.1 Make it clear where there are universal requirements for minimum functionality. [Priority 1]
5.2 Make it clear when conformance requirements are strict. [Priority 1]
5.3 Make it clear where requirements stop and product-specific extra features begin. [Priority 1]
5.4 If special conformance terms are used, include a definition in the specification. [Priority 1]
Guideline 6. Clarify the relation between deprecated features and conformance.
[...Required: per-Guideline summary/overview verbiage goes here...]
6.1 Identify and clearly indicate each deprecated feature. [Priority 1]
6.2 For each class of product, specify the level of support required for each deprecated feature and the conformance consequences of the deprecation. [Priority 1]
6.3 Include an explanation for the deprecation. [Priority 3]
6.4 Include examples to illustrate how to avoid using deprecated features. [Priority 3]
6.5 Include a table of contents entry. [Priority 2]
Guideline 7. Address the use of levels to divide the specification.
[...Required: per-Guideline summary/overview verbiage goes here...]
7.1 Address whether or not the specification will use levels. [Priority 1]
7.2 Include a table of contents entry. [Priority 1]
7.3 If levels are used, define their relationships and interaction with other dimensions of variability. [Priority 2]
Guideline 8. Define discretionary items.
[...Required: per-Guideline summary/overview verbiage goes here...]
8.1 Explicitly state the cases and conditions where discretionary choices are allowed. [Priority 2]
8.2 Indicate implementation dependencies and address allowable differences between implementations, where applicable. [Priority 1]
8.3 Describe alternative approaches and the conditions under which an implementation is considered to be conforming. [Priority 1]
8.4 Include a statement regarding consistent handling of a discretionary item within an implementation. [Priority 2]
8.5 Include a table of contents entry. [Priority 2]
Guideline 9. Allow extensions or NOT!
[...Required: per-Guideline summary/overview verbiage goes here...]
9.1 If extensions are disallowed, explicitly state it. [Priority 3]
9.2 If extensions are allowed, explicitly state it. [Priority 1]
9.3 If extensions are allowed, make it clear that the extensions do not negate support for required functionality. [Priority 1]
9.4 If extensions are allowed, use a standard mechanism to define the extension. [Priority 3]
9.5 If extensions are allowed, register or publish them. [Priority 3]
9.6 If extensions are allowed, require that implementations include a way to operate without the extension. [Priority 3]
9.7 Include a table of contents entry. [Priority 2]
Guideline 10. Provide a conformance clause.
[...Required: per-Guideline summary/overview verbiage goes here...]
10.1 Include a conformance clause. [Priority 1]
10.2 Create a separate conformance section. [Priority 2]
10.3 Include a conformance clause entry in the table of contents. [Priority 2]
10.4 Make normative reference to specifications on which the current specification depends. [Priority 2]
Guideline 11. Specify how to make conformance claims.
[...Required: per-Guideline summary/overview verbiage goes here...]
11.1 Identify and define all conformance designations. [Priority 1]
11.2 Provide specific wording of the claim. [Priority 3]
11.3 Provide a conformance disclaimer. [Priority 3]
11.4 Impose no restrictions about who can make a claim or where claims can be published. [Priority 1]
11.5 Include a table of contents entry. [Priority 2]
Guideline 12. Publish an Implementation Conformance Statement proforma.
[...Required: per-Guideline summary/overview verbiage goes here...]
12.1 Include an Implementation Conformance Statement proforma as part of the specification. [Priority 3]
12.2 Require the ICS be completed as part of the conformance claim. [Priority 3]
Guideline 13. Support general document conformance conventions.
[...Required: per-Guideline summary/overview verbiage goes here...]
13.1 Use conformance key words. [Priority 1]
13.2 Distinguish normative and informative text. [Priority 2]
13.3 Follow Web Accessibility Initiative and Internationalization Guidelines. [Priority 1]
13.4 Use the same words to express the same ideas. [Priority 1]
Guideline 14. Use granular grammars to author the specification.
[...Required: per-Guideline summary/overview verbiage goes here...]
14.1 Use W3C endorsed grammar where applicable. [Priority 1]
14.2 Specify intended behavior in the specification using markup. [Priority 1]
14.3 Supply prose description of intended behavior together with each test assertion. [Priority 1]
Guideline 15. Include test assertions.
[...Required: per-Guideline summary/overview verbiage goes here...]
15.1 Supply test assertions in the markup of the specification, if applicable using a set of predefined tags used in the specification markup language. [Priority 1]
15.2 Tag test assertions according to the above. [Priority 1]
[Optional: opinions, observations, assessment, judgements, etc, about the subject of your review, about the review process, the Guidelines document, etc.]