Re: SpecGL: rewrite of Strict Conformance

David

I agree with Mark.  I think you are reading way to much into strict 
conformance.  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 17:59:18 UTC