Re: profiles/modules/levels

You're giving me a headache.  My responses are in-line.


At 03:03 PM 4/29/2003 -0600, Lofton Henderson wrote:
>At 03:07 PM 4/29/03 -0400, Mark Skall wrote:
>
>>>In my view, all of GL9 (extensions) is about functional extensions to 
>>>the technology.  It is not about ways in which a spec's conformance 
>>>model (or conformance policy), per se, might exceed and extend SpecGL's 
>>>concepts.  A new DoV, or a generic catch-all DoV, is about the latter.
>>
>>I strongly disagree.
>
>No wonder.  I think we're talking about different things...
>
>> From SpecGL " An extension to a specification is a mechanism to 
>> incorporate functionality beyond what is defined in a 
>> specification."  You're interpreting "functionality" too narrowly. The 
>> intent is to allow implementations to do things above and beyond the 
>> requirements in the standard.  We're now talking about extending SpecGL 
>> in an implementation of it.  Our "functionality" are all the 
>> requirements in SpecGL (everything with a conformance requirement in the 
>> form of "MUST".  Implementations of SpecGL are specifications and when 
>> these specifications include additional concepts that were not 
>> enumerated in SpecGL, that's clearly an extension.
>
>We're talking about different things.  When you talk about GL9 Extensions, 
>you're talking about conformance of a target specification to 
>SpecGL.  When I was talking about GL9 extensions, I was talking about 
>conformance of an implementation (of some Class of Product of the 
>specification) to the target specification.

Huh?  We can only define checkpoints for conformance to our Spec (i.e., 
what must a target spec do to conform?)  Conformance of an implementation 
to the target spec is only addressed by the target spec's conformance section.

>Andrew's original comment was this:  "At the moment we have specific 
>checkpoints for p, m and l. But if someone wants to use a new type of Dov 
>called 'personality' or whatever then SpecGL is silent."

And these checkpoints apply specifically to how a target spec implements 
SpecGL's requirements.  SpecGL is silent on "personality" because you can't 
give guidance on what you don't yet know (silence can be golden).

>So, if "someone", i.e., a target specification, wanted to talk about its 
>own conformance to SpecGL, then yes, the new DoV could be described as an 
>extension to SpecGL.  However, SpecGL does not require that a target 
>specification say anything about its own conformance to SpecGL.  Therefore 
>the target specification in fact does not have to talk about new-DoV as a 
>dimension of variability, or describe its relationship to other DoV, or 
>any of the things that we *do* require target specifications do for DoV.

Correct.  But it can (through a conforming extension) talk about it 
specifically, rather than in general terms.  Also, I'm not sure why someone 
would add this new DOV.  The point is to give guidance about when and why 
to use P, M and L's.  I think we should actually discourage other ways to 
do very similar things.

>Look at it another way.  If target specification uses 'profiles', then 
>SpecGL requires that the target specification talk about it.  If target 
>specification, in its conformance policy, defines a new way in which 
>conformant target implementations of target specification may vary (i.e., 
>a new dimension, "new-DoV"), then "SpecGL is silent".  Nothing in SpecGL 
>requires that target specification discuss it.

Yes, but how can we require the target spec to discuss "it" when "it" is 
unknown.

>If in fact you are saying that SpecGL's extensions guideline (GL9) somehow 
>requires that target specification discuss the nature its new-DoV and 
>interrelationships with Enumerated DoV, that is a surprising 
>interpretation of GL9 to me.  I just reread all of GL9, and I strongly 
>disagree.


No, I am not saying that.  What I am saying is that we can't impose 
requirements on something unknown.  If all you want is a simple statement 
that says that any new DOV extension (again this is an extension which, I 
believe, was the original argument) MUST talk about relationship to P, M, 
and L's, I guess that's okay, but it doesn't really help much. (Remember 
your argument that we couldn't combine ckpts of P, M, L's because you 
couldn't generecize them?  If we can't genericize them for ckpts, how can 
we do it now?)

IMO, the real value of P, M, L's is that it gives explicit options to spec 
developers as to how to sub-divide the spec.  That's the reason we need to 
better define what they each are and when to use them.  Requiring specs to 
discuss yet undefined concepts seems to me to be adding yet more 
requirements without any real benefits.

P.S.  I still don't understand your statement that "When I was talking 
about GL9 extensions, I was talking about conformance of an implementation 
(of some Class of Product of the specification) to the target 
specification."  What does the conformance of an implementation to the spec 
have to do with anything we've been discussing?

****************************************************************
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 Tuesday, 29 April 2003 17:51:41 UTC