Re: SpecLite: extensions

>
>Huh?  I'm sure that I must be misunderstanding your point here.  Because 
>what I hear you saying is contrary to a significant and long-established 
>body of practice.

Perhaps your body of practice, not mine.


>How can a profile conform to the base standard?


IMO, a profile "conforms" to a base standard if it chooses 
functionality/features from within that standard.  When it defines new 
functionality (or new features) it is not really a profile of that 
particular standard.  As an extreme case, let's say a profile of CGM 
defines all new features (i.e., it redefines CGM) and uses none of the 
features of CGM. (Thus, it's not using GDP/Escapes to add new 
functionality, but defining new features to add new functionality). Is that 
a conforming CGM profile?  I think not.  You may choose to use another word 
than "conforms", but in any case, the profile is illegal wrt to the base 
standard.  I think "conforms" is the most appropriate word and it's the one 
I've always used.

>A Class of Product conforms to some applicable conformance requirements of 
>a base standard.  Typically a CoP is something like a generator or 
>interpreter of a standardized format.  If, and only if, the base standard 
>contains "Rules for Profiles", then a profile can conform or not to the 
>base standard.  Otherwise the question "does profile conform to base 
>standard" is meaningless.

Ok, but we're getting far away from the main argument.  The "Rules for 
Profiles" should talk about only using functionality/features already 
defined. Profiles are supposed to sub-divide, or partition, existing 
functionality - that's my only point.  Remember, in SpecGL we talk about 
ways to sub-divide the spec - profiles, levels, modules.  To my 
recollection, we certainly don't use the term "extensions" to say we can 
not only sub-divide, but sub-divide and add.  Of course "extensions" still 
apply to these profiles, etc. if an implementor adds funcitonality/features 
to them when implementing them.

>I think you are confusing "a profile shall not contradict the base 
>standard" with a broader notion of conformance of a profile to the base 
>standard.  A profile can define and allow some extensions, and not 
>contradict the base standard, and conform to the base standard.

Defining and allowing extensions is what all standards can do.  We say this 
in SpecGL - first define what you mean by an extension and then say whether 
or not they're allowed.  This is completely different that defining new 
features in the profile and calling that an extension.

>Example.  ISO CGM has Rules for Profiles (RfP).  (These were added to ISO 
>CGM around 1995, and have been considered by many to be an early example 
>of good practice in the field).  The RfP define some terms and conditions 
>(T&C) about extensions.  A profile may define and allow extensions, and 
>still be conforming to RfP, if certain T&C are met.


Again, this is different than what you were saying earlier.  Yes, a profile 
may define and allow extensions (to the profile).  That's using 
"extensions" in exactly the way I am talking about.  It's allowing an 
implementation to use additional features.

>   WebCGM defines extensions and meets the RfP, therefore it conforms to 
> the CGM base standard.  ATA does the same.  AECMA does the same.  Etc...

Again, there are 2 separate concepts here.  (1). Defining and allowing 
extensions and (2). calling new features in these profiles "extensions". 
You've said the former is done.  I'm still not sure if you are saying that 
the latter is done. The former is precisely the way extensions should be 
used, IMO.


>>>>[...]In summary, I don't see the need to use and define the term 
>>>>"extensibility",
>>>
>>>Nevertheless, we *do* use it all the time, in talking and in writing, 
>>>and will likely continue to do so.

I think this is an overstatement.  I talk a lot about standards, etc. as 
does everyone at NIST.  I can honestly say I've never heard the word 
"extensibility" come up.  It may be in our documents, but I don't think we 
ever made a conscious choice to include that term.

>>But we don't have to use it in the QA framework documents.
>
>The terms are in common use in our own documents for 2+ years, and in the 
>world at large as well (e.g., the citations I gave to WebArch).  IMO, it 
>would be folly to try to ignore this.  This is like the glossary trying 
>force the world, instead of precisely explain the world.  (Clearly I 
>believe in the latter, but maybe that belief is not shared.)
>
>>[...]
>>Again, I defined extensions above and I think we should eliminate 
>>"extensibility"
>
>As you can tell, I strongly disagree with the latter.
>
>Over and out,
>-Lofton.
>
>
>

****************************************************************
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 Wednesday, 28 April 2004 09:51:49 UTC