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

Re: SpecGL: rewrite of Strict Conformance

From: Mark Skall <mark.skall@nist.gov>
Date: Fri, 17 Jan 2003 09:42:26 -0500
Message-Id: <>
To: Lynne Rosenthal <lynne.rosenthal@nist.gov>, Lofton Henderson <lofton@rockynet.com>
Cc: www-qa-wg@w3.org

At 08:50 AM 1/17/2003 -0500, Lynne Rosenthal wrote:

>Yes.  It should be "i.e., no extensions".   I was a bit sloppy, when I 
>first sent this out.   So it should now read.....
>Disallowing extensions for any part of the specification is called strict 
>conformance.  Strict conformance is defined as conformance of an 
>implementation that employs only the requirements and/or functionality 
>defined in the specification and no more (i.e., no extensions to the 
>specification are implemented).
>I would like to keep this simple. Basically strict conformance = no 
>If people think there is still confusion we could add the following with 
>respect to DoV
>"Dimensions of variability (e.g., modules, profiles, levels) are not 
>extensions if the specification defines them or allows them to be defined."

I like this.  it states unequivocally what some of us have been saying.

>My preference is not to add anything about DoV - I think that is what is 
>adding to the confusion.

I still think there is confusion, based on the discussion.  I think it's a 
mind set (the term "strict" in "strict conformance" implies, in some 
people's mind, an exact match of all implementations, and thus equivalent 
DOVs).  Thus, I think the sentence you suggested would eliminate any confusion.

>  IMO the confusion in Seattle and the issue, was because the text in GL3 
> was confusing, introduced confusion by talking about DoV and was using 
> the definition of strict conformance erroneously in places.
>At 08:15 PM 1/16/2003, Lofton Henderson wrote:
>>At 05:58 PM 1/16/03 -0500, Lynne Rosenthal wrote:
>>>I agree with Mark.  I think you are reading way to much into strict 
>>I fell into this trap also, and I think it was because "e.g., no 
>>extensions" in the verbiage is what stuck in my mind, instead of "i.e., 
>>no extensions" (as it is in the glossary.)
>>>All it is, is another way of saying extensions are not allowed.  Strict 
>>>conformance does not prevent a spec from having levels (modules, 
>>>profiles or choices) as long as it defining (describing) them or 
>>>explicitly states that you can have levels, modules, etc.
>>>At 04:55 PM 1/16/2003 -0500, Mark Skall wrote:
>>>>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"?
>>>>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.
>>>>>Lynne proposes:
>>>>> >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.
>>>>>As a way to confirm your intent, I deduce that the "strict conformance"
>>>>>definition in GL 9 actually relates to several DoV as enumerated below.
>>>>>Strict Conformance means *all* of the following are true:
>>>>>(GL 6) there are no levels (unclear)
>>>>>(GL 7) no variation is allowed in treatment of deprecated features
>>>>>(GL 8) no discretionary items exist in the spec
>>>>>(GL 9) no extensions are allowed
>>>>I don't think that was Lynne's intent and I certainly would disagree 
>>>>with this.
>>>>>On the other hand, the strict conformance policy can apply only to some
>>>>>of the product classes (GL 2), some profiles (GL 4), or some modules
>>>>>(GL 5). If true, this validates the numerical order of the guidelines
>>>>>going from general to specific. (It still would if GL 6 "crossed the
>>>>>line" and Strict Conformance applied on a per-level basis.)
>>>>>I would like the wording to be explicit about profiles, modules, and
>>>>>levels. I think that Strict Conformance should mean that there are no
>>>>>levels, as part of the goal to make it a useful term.
>>>>Again, I strongly disagree.  That would re-define the definition of 
>>>>"strict conformance."
>>>>>Notice that the interaction between the definition and deprecation is
>>>>>slightly different than the others. Deprecation is compatible with
>>>>>Strict Conformance, as long as you don't have discretionary choices (GL 8)
>>>>>regarding the deprecated features. Fine point: if all implementations
>>>>>must consume deprecated content and treat it in some specified way (e.g.,
>>>>>must ignore it), does the discretionary choice of whether to warn the
>>>>>user about deprecated input violate Strict Conformance? If so, we are
>>>>>being really strict, because issuance of warnings might be a minor
>>>>>secondary effect to most (but not all) implementors.
>>>>>.................David Marston
>>>>Mark Skall
>>>>Chief, Software Diagnostics and Conformance Testing Division
>>>>Information Technology Laboratory
>>>>National Institute of Standards and Technology (NIST)
>>>>100 Bureau Drive, Stop 8970
>>>>Gaithersburg, MD 20899-8970
>>>>Voice: 301-975-3262
>>>>Fax:   301-590-9174
>>>>Email: skall@nist.gov

Mark Skall
Chief, Software Diagnostics and Conformance Testing Division
Information Technology Laboratory
National Institute of Standards and Technology (NIST)
100 Bureau Drive, Stop 8970
Gaithersburg, MD 20899-8970

Voice: 301-975-3262
Fax:   301-590-9174
Email: skall@nist.gov
Received on Friday, 17 January 2003 09:50:53 UTC

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