Re: profiles/modules/levels

I think I agree with Mark's explanation.  The SpecGL (at least v1.0) should 
address items that are critical and 'most common' in developing a 
specification.   A goal is to help spec developers by providing them with 
items that need to be in their specifications and/or considered for 
inclusion.  A problem of trying to think of everything or to include a 
'catch-all' is that we end up with something that is useless and/or 
confusing.  Note, that we tried to do this with G3 and only a few people 
understand its purpose as a catch-all guideline.

To finish, and back to the point --- By having the current DoV (p/m/l), it 
provides spec developers with the right mind set - that is, thinking about 
how they want to divide the technology and the consequences of doing 
so.  They could invent a novel new DoV - SpecGL doesn't prohibit this (we 
can't think of everything).  And, hopefully, they will consider the 
consequences of inventing this new DoV and model it after what is currently 
in SpecGL.

lynne


At 06:11 PM 4/29/2003 -0400, Mark Skall wrote:

>I think I now see the motivation behind much of this discussion.  Andrew, 
>you seem to perceive that adding new DOVs (outside of the ones SpecGL 
>requires) to specs will be judged as extensions and, thus, thought of, in 
>some bad light.
>
>I think we have to look at "extensions" to SpecGL as a different kind of 
>animal that extensions to target specs.  Extensions to target specs add 
>new functionality that obviously harm interoperability.
>
>Let's remember that SpecGL puts requirements on spec developers who then 
>put requirements on (real) implementers.  The requirements we put on spec 
>developers are only the ones that we thought of during the time of SpecGL 
>development.  I think it would be very naive to think that we've thought 
>of everything.  I believe almost all new specs will include things we 
>haven't thought of, either because they were so trivial or because we 
>weren't smart enough.
>
>So my conclusion is twofold: 1) I think that just about every spec 
>developed will have "extensions" to our list of requirements; 2) I don't 
>think these extensions are necessarily harmful or a danger to 
>interoperability if they are well thought out.
>
>Mark
>
>
>
>At 10:57 PM 4/29/2003 +0100, Andrew Thackrah wrote:
>
>
>
>>Hi Mark,
>>One concern I have about this explanation is that a spec author
>>may not regard a DoV as being an extension. If a new-DoV [to use
>>  Lofton's word] is engineered into the spec from the early days then
>>I think that the authors would be confused if we told them that it
>>counted as an extension.
>>Even though I'm closer to SpecGL than many spec author's may ever be
>>I still find this argument a subtle one, even though it seems
>>technically good.
>>
>>-Andrew
>>
>>On Tue, 29 Apr 2003, Mark Skall wrote:
>>
>> >
>> > At 02:32 PM 4/29/2003 +0100, Andrew Thackrah wrote:
>> > >
>> > >But what if the spec author choses another type of architecture that we
>> > >have not thought of? My argument is about this case. I want to make sure
>> > >that our
>> > >checkpoints address this possibility. 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. So I am arguing
>> > >that when we roll the checkpoints into a single GL, we should keep the
>> > >specific checkpoints for the important concepts of p/m/l but ensure that
>> > >we have general checkpoints too.
>> >
>> >
>> > An implementation can be conformant to SpecGL and include extensions.  If
>> > someone wants to use another form of DOV, they may.  That is a 
>> (conformant)
>> > extension.  Since there is no way of pre-determining what kind of DOV (or
>> > any other type of extension) someone may choose to include there is 
>> nothing
>> > to gain by having general checkpoints.  The general checkpoint would be
>> > redundant.
>> >
>> > Mark
>
>****************************************************************
>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 19:53:48 UTC