|
Guideline 1. Include a conformance clause
|
| Nbr |
Checkpoint |
Priority |
Yes |
No |
N/A |
|
1.1 |
Use conformance key words (RFC2119) consistently and
appropriately
|
[Priority 1]
|
|
|
|
|
1.2 |
Create a separate conformance section
|
[Priority 2]
|
|
|
|
|
1.3 |
Generate a conformance clause entry in the table of
contents
|
[Priority 2]
|
|
|
|
|
1.4 |
Label normative and informative sections
|
[Priority 2]
|
|
|
|
|
1.5 |
Make normative reference to specifications on which
the current specification depends.
|
[Priority 1]
|
|
|
|
|
Guideline 2. Specify all flavors of conformance
|
| Nbr |
Checkpoint |
Priority |
Yes |
No |
N/A |
|
2.1 |
Define all flavors of conformance that are applicable
to the specification
|
[Priority 1]
|
|
|
|
|
Guideline 3. Identify what needs to conform and how
|
| Nbr |
Checkpoint |
Priority |
Yes |
No |
N/A |
|
3.1 |
Identify all classes of product
|
[Priority 1]
|
|
|
|
|
3.2 |
For each class of product, define the conformance
requirements
|
[Priority 1]
|
|
|
|
|
3.3 |
Indicate minimal support requirements.
|
[Priority 3]
|
|
|
|
|
Guideline 4. Use modularization or profiling to group requirements
|
| Nbr |
Checkpoint |
Priority |
Yes |
No |
N/A |
|
4.1 |
Choose one or more of the following methods for
grouping or dividing up the specification: a) modulization, b) profiling, c)
none of the above
|
[Priority 1]
|
|
|
|
|
4.2 |
For a, and/or b, indicate whether its use is
mandatory
|
[Priority 1]
|
|
|
|
|
4.3 |
For a, b, and/or c, indicate the conditions for
claiming conformance
|
[Priority 2]
|
|
|
|
|
Guideline 5. Specify how to make a conformance claims
|
| Nbr |
Checkpoint |
Priority |
Yes |
No |
N/A |
|
5.1 |
Identify and define all conformance levels
|
[Priority 1]
|
|
|
|
|
5.2 |
Provide specific wording of the claim
|
[Priority 3]
|
|
|
|
|
5.3 |
Impose no restrictions about who can make a claim or
where claims can be published
|
[Priority 1]
|
|
|
|
|
Guideline 6. Define discretionary behaviors
|
| Nbr |
Checkpoint |
Priority |
Yes |
No |
N/A |
|
6.1 |
Explicity state the cases and conditions where
discretion is allowed and/or expected.
|
[Priority 2]
|
|
|
|
|
6.2 |
Indicate implementation dependencies and where
applicable address allowable differences between implementations.
|
[Priority 1]
|
|
|
|
|
6.3 |
Describe alternative approaches and the conditions
under which an implementation is considered to be conforming
|
[Priority 1]
|
|
|
|
|
6.4 |
Include a statement regarding consistent handling of a
discretionary item within an implementation.
|
[Priority 2]
|
|
|
|
|
Guideline 7. Clarify the relation between depricated features and
conformance
|
| Nbr |
Checkpoint |
Priority |
Yes |
No |
N/A |
|
7.1 |
Identify and clearly indicate each deprecated
feature
|
[Priority 1]
|
|
|
|
|
7.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]
|
|
|
|
|
7.3 |
Include an explanation for the deprecation.
|
[Priority 3]
|
|
|
|
|
7.4 |
Include examples to illustrate how to avoid using
deprecated features
|
[Priority 3]
|
|
|
|
|
Guideline 8. Allow extensions or NOT!
|
| Nbr |
Checkpoint |
Priority |
Yes |
No |
N/A |
|
8.1 |
If extensions are disallowed, explicitly state it.
|
[Priority 3]
|
|
|
|
|
8.2 |
If extensions are allowed, explicity state it.
|
[Priority 1]
|
|
|
|
|
8.3 |
If extensions are allowed, make it clear that the
extensions do not negate support for required functionality.
|
[Priority 1]
|
|
|
|
|
8.4 |
If extensions are allowed, use a standard mechansim to
define the extension
|
[Priority 3]
|
|
|
|
|
8.5 |
If extensions are allowed, register or publish them
|
[Priority 3]
|
|
|
|
|
8.6 |
If extensions are allowed, require that
implementations include a way to operate without the extension.
|
[Priority 3]
|
|
|
|
|
Guideline 9. Publish an Implementation Conformance Statement
proforma
|
| Nbr |
Checkpoint |
Priority |
Yes |
No |
N/A |
|
9.1 |
Include an Implementation Conformance Statement
proforma as part of the specification.
|
[Priority 3]
|
|
|
|
|
9.2 |
Require the ICS be completed as part of the
conformance claim.
|
[Priority 3]
|
|
|
|
|
Guideline 10. Include test assertions
|
| Nbr |
Checkpoint |
Priority |
Yes |
No |
N/A |
|
10.1 |
Detailed control over what parts of a specification an
implementation supports, grouped by behaviour, technical aspect
(method/interface) or othre conceptual grouping
|
[Priority 3]
|
|
|
|
|
10.2 |
Detailed reporting when testing an implementation
using the test
|
[Priority 3]
|
|
|
|
|
10.3 |
Tag testable statements
|
[Priority 3]
|
|
|
|
|
Guideline 11. Use granular grammars to author the specification
|
| Nbr |
Checkpoint |
Priority |
Yes |
No |
N/A |
|
11.1 |
Use W3C endorsed grammar [needs to be further
formalize, DD to look into what DTD/Schemas exist and are presently used]
|
[Priority 3]
|
|
|
|
|
11.2 |
Specify intended behaviour in the specification using
markup
|
[Priority 3]
|
|
|
|
|
11.3 |
Supply prose description of intended behaviour
together with each test assertion
|
[Priority 3]
|
|
|
|