[SpecGL Draft] Conformance Clause

Conformance

Conformance to the QA Framework: Specification Guidelines is very simple.
    * It applies to one class of product – Working Group specifications 
(i.e., technical reports).
    * It is monolithic – no modules, levels or profiles are defined.
    * It has only one conformance label, called ‘conformance’.
    * It has options, but the options do not affect conformance.
    * It allows extensions, but the extensions do not affect conformance.
The conformance requirements of this document are denoted as 
Principles.  All Principles are written in imperative voice, with the 
assumed “you must’ in front of the statement.  In addition to Principles, 
the document contains Good Practices.  Good Practices are optional and 
considered recommendations.  Their implementation or non-implementation 
does not affect conformance to this Specification Guidelines document.

To conform to this Specification Guidelines, all Principles must be 
implemented.

One way to satisfy the Principles and Good Practices is to implement one or 
more of the suggested techniques given for each Principle and Good 
Practice.  Note that this is not the only way to satisfy the Principle or 
Good Practice.  An Implementation Conformance Statement is provided for 
assistance in keeping track of which Principles and Good Practices are 
implemented.  It takes the form of a checklist.  If all the Principles are 
checked as being satisfied, then conformance can be claimed.  [Karl – can 
you extract the Principles and GPs to create a checklist, and make this an 
Appendix?]

Normative parts

The normative parts of this specification are identified by markup and 
style as well as the labels, ‘normative’ and ‘informative’ within 
sections.  [Karl- I’m assuming that we are labeling things, if not, remove 
this part of the sentence].   The following list indicates the normativity 
of parts in this specification.
             Principles                      Normative
             Good Practice              Normative
             What does this mean?   Informative
             Why Care?                   Informative
             Techniques                   Informative [or is this normative?]
             Examples                      Informative

Text that is designated as normative is directly applicable to achieving 
conformance to this document.  Informative parts of this document consist 
of examples, extended explanations, and other matter that contains 
information that should be understood for proper implementation of this 
document.

Extensibility

This specification is extensible.  That is, adding conformance related 
information and structure to the document in ways beyond what is presented 
as Principles in this specification, is allowed and encouraged.  Extensions 
to this specification must not contradict nor negate the requirements in 
this specification.

Conformance claims

To claim conformance to the QA Framework: Specification Guidelines, Working 
Groups must specify:
    * guidelines title and dated URI: QA Framework: Specification 
Guidelines, URI
    * URI of a dated version of the specification for which conformance is 
being claimed,
    * date of the claim.
Example:
On 1 October 2004, W3C’s QA Handbook 
(<http://www.w3.org/TR/2004/>http://www.w3.org/TR/2004/???) dated XX 
September 2004 conforms to W3C’s QA Framework: Specification Guidelines, 
available at 
<http://www.w3.org/TR/2004/WD-qaframe-spec-2004????/>http://www.w3.org/TR/2004/WD-qaframe-spec-2004????/. 


On 1 October 2004, W3C’s QA Framework: Specification Guidelines 
(<http://www.w3.org/TR/2004/>http://www.w3.org/TR/2004/WD-qaframe-spec-2004????/) 
dated XX September 2004 conforms to W3C’s QA Framework: Specification 
Guidelines, available at 
<http://www.w3.org/TR/2004/WD-qaframe-spec-2004????/>http://www.w3.org/TR/2004/WD-qaframe-spec-2004????/.