Re: SpecGL: rewrite of Strict Conformance

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:04:11 UTC