Re: [SpecGL Draft] Conformance Clause

Yes.  I realized that as well.

Makes sense to change Good Practices to Informative.
Otherwise, we need to reopen our definition of Normative.

I still think we should have an ICS that includes both Principles and Good 
Practices.  People will want to see what they do, regardless of it being a 
P or GP

--lynne

At 11:17 AM 8/19/2004, Lofton Henderson wrote:

>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/>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/WD-qaframe-spec-2004????/>http://www.w3.org/T 
> R/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????/.
> >
>
>
>
>