Re: SpecGL: rewrite of Strict Conformance

At 04:55 PM 1/16/03 -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.

Yes.  I would suggest that we ought to work on the verbiage a little 
more.  In particular (as I noted in earlier message), the last sentence in 
Lynne's proposed paragraph (below) needs to be fixed.  Also, I think your 
third sentence (above) would be useful to add to the verbiage.   The fact 
that this came up as a formal issue, was discussed at Seattle, and yet 
there are still questions about what we meant -- this could be taken as 
indicating that we aren't being clear (and/or complete) enough in our 
explanation.


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

Fair enough, but fix "no discretion is granted to implementers", since we 
have this entire GL8 about the "discretion" DoV, which is all permissible 
under "strict".

Also, I notice the "e.g." in the above verbiage:  "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)."

This isn't correct, is it?  Isn't it "i.e." instead?  How about changing 
the parenthetical clause to a new sentence: "...and no more. Strict 
conformance means that no extensions to the specification are 
implemented."  Or, "Strict conformance means that the conformance 
definitions of the specification prohibit extensions in implementations."

(Hmmm... is "strict" an attribute of the conformance definitions of 
specifications -- i.e., the conformance definitions of a specification 
prohibit extensions in implementations.  Or is it an attribute of 
implementations of specifications -- i.e. implementations don't employ 
extensions (or "no extensions to the specifications are implemented")?  We 
mean the first, right?)


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

Now (after Seattle discussion) that I better understand the intent of 
"strict conformance", I agree with Mark here.  I don't see the problem with 
levels -- they are well-defined standard functionality.  As are 
"discretionary choices" and "optional features" (I still disagree that 
"implementation-dependent values or features" should be permissible under 
"strict").  As are deprecated features.  They are all well-defined and 
standardized forms of variability or optionality, unlike extensions.

-Lofton.

Received on Thursday, 16 January 2003 20:04:11 UTC