W3C home > Mailing lists > Public > www-qa-wg@w3.org > January 2003

Re: SpecGL: rewrite of Strict Conformance

From: Lofton Henderson <lofton@rockynet.com>
Date: Thu, 16 Jan 2003 16:59:50 -0700
Message-Id: <>
To: Lynne Rosenthal <lynne.rosenthal@nist.gov>
Cc: www-qa-wg@w3.org
Before I look at the details of the subsequent comments of Mark and David, 
I have one suggestion (see end)...

At 03:11 PM 1/16/03 -0500, you wrote:
>Below completes my action item to review Guideline 3 and 9 with respect to 
>Strict Conformance and to proposed modifications.
>For Guideline 3. Specify conformance policy
>1.  Modify 1st paragraph, (changes start with the second sentence)
>A look at various W3C Technical reports shows that the term "conformance" 
>is often qualified, resulting in more than one type of conformance.  It is 
>important to convey an understanding of what is meant by conformance and 
>how it applies to each class of product as well as each dimension of 
>variability (e.g., modules) if applicable. For example, if the 
>specification defines behavior for more than one class of product, there 
>may be a separate conformance policy for each class.  Similarly, if the 
>specification defines modules, there may be a different conformance policy 
>for each module.
>2.  Delete the 2nd, 3rd, and 4th paragraphs.
>3. The 5th paragraph  the definition of Strict conformance is moved to 
>Guideline 9 (see below).
>4. Leave the last 2 paragraphs (6 and 7) as is.
>5.  Remove Checkpoint 3.2.  It is subsumed by ckpt 9.1.
>6.  Checkpoint 3.3 should be removed
>7. Ckpt 3.1  (I wasn't sure what is meant here, but with Mark's help, I 
>thought that this was it)
>Propose alternative wording for the fulfill criteria of Ckpt 3.1
>To fulfill this checkpoint, a specification MUST include a normative 
>section enumerating the minimal requirements that apply across all 
>products of a class.
>Rationale: the reader must be able to recognize any minimum functionality, 
>complexity or support that applies to all conforming products of a 
>specific class.
>For Guideline 9. Extensions or NOT.
>8.  Insert the following as the 3rd paragraph in Guideline 9
>Disallowing extensions for any part of the specification is called strict 
>conformance.  [te paragraph from G3]  Strict conformance is defined as 
>conformance of an implementation that employs only the requirements and/or 
>functionality defined in the specification and no more (e.g., no 
>extensions to the specification are implemented).  No discretion is 
>granted to implementers, and any requirements for handling deprecated 
>features must be followed.

"No discretion is granted to implementers," is a bad choice of words.  As I 
recall from Seattle (Tues PM), strict conformance applies only to 
functional extensions.  I thought that we discussed, and decided, that 
discretionary items are allowed under strict conformance.  In which case, 
indeed there is discretion granted to implementers.  Some of us thought the 
term "strict conformance" was misleading, if it in fact allows several bits 
of variability like discretion, extended capability of standard functions, 
etc.  However, I (at least) accepted that this was a legacy definition 
(from NIST?), and withdrew my objections.

Unfortunately, this "discretion" detail is not documented in the draft 
minutes.  However, from the following excerpt from later in this thread, it 
sounds like Mark remembers the same.

>At 04:21 PM 1/16/2003 -0500, David Marston/Cambridge/IBM wrote:
>The major dilemma we had was as follows:
>A product could vary along some Dimensions of Variability, notably
>discretionary choices, but not implement any extensions. Is this
>"strict conformance"?
>[Mark's reply...] This is still "strict conformance." The term 
>"conformance" has to do with implementing features exactly as allowed in 
>the spec/rec. Thus, implementing the DOVs not having to do with extensions 
>does not violate "strict conformance." I think our original definition of 
>"strict conformance" bears this out.

If all of this is an accurate remembrance (and if we do not further modify 
this issue resolution), then ""No discretion is granted to implementers," 
ought to be changed, as it is pretty misleading.

(I may have more substantive comments, later, after I have digested the 
MS/DM dialog.)

Received on Thursday, 16 January 2003 18:57:36 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:43:32 UTC