Re: [SpecGL Draft] Conformance Clause

If good practices are optional and recommendations,  then why are they
normative - which is supposed to directly influence conformance?


Sent from my BlackBerry Wireless Handheld

-----Original Message-----
From: <>
To: <>; Karl Dubost <>
Sent: Thu Aug 19 09:29:37 2004
Subject: [SpecGL Draft] Conformance Clause

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
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
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.  
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. 

On 1 October 2004, W3C's QA Handbook ( dated
XX September 2004 conforms to W3C's QA Framework: Specification Guidelines,
available at 
On 1 October 2004, W3C's QA Framework: Specification Guidelines
( dated XX September
2004 conforms to W3C's QA Framework: Specification Guidelines, available at 

Received on Thursday, 19 August 2004 15:02:34 UTC