Re: SpecGL: rewrite of Strict Conformance

At 05:58 PM 1/16/03 -0500, Lynne Rosenthal wrote:

>David
>
>I agree with Mark.  I think you are reading way to much into strict 
>conformance.

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

-Lofton.

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

Received on Thursday, 16 January 2003 20:13:27 UTC