Re: [SpecGL Draft] Conformance Clause

At 11:02 AM 8/19/2004 -0400, Mark W. Skall wrote:

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

I had the same question.

SHOULDs (i.e., Good Practices) would only have an effect on conformance, it 
would seem, if there were an additional conformance designation.  For 
example, if there were two designations, "Conforming" and "Conforming 
PLUS", and

all PRs = "Conforming"

all PRs + some GPs = "Conforming PLUS"

then the GPs would clearly affect conformance and be normative.  I think I 
see the possible thinking behind the normative label for GPs:  we'd like 
you to do these, and they will benefit your specification, and if you do 
them then they must (or should?) be done like this.  But ... the 
definitions and concepts aren't exactly meshed here.

Another question.  Should we have a checklist of all PRs and GPs?  (And 
maybe consider it to be an ICS for SpecGL?).

-Lofton.

>--------------------------
>Sent from my BlackBerry Wireless Handheld
>
>
>-----Original Message-----
>From: www-qa-wg-request@w3.org <www-qa-wg-request@w3.org>
>To: www-qa-wg@w3.org <www-qa-wg@w3.org>; Karl Dubost <karl@w3.org>
>Sent: Thu Aug 19 09:29:37 2004
>Subject: [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/???) dated
>XX September 2004 conforms to W3C's QA Framework: Specification Guidelines,
>available at 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/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????/.
>

Received on Thursday, 19 August 2004 15:17:50 UTC