Re: new version of SpecLite - Extensions

At 07:31 AM 5/7/2004 -0600, Lofton Henderson wrote:
>At 12:10 PM 5/4/2004 -0400, Mark Skall wrote:
>
>>>Having said that, I should comment on The Skallian Hypothesis
>>
>>Sounds like a very elegant name for an 18th century scientific theory (or 
>>perhaps just the name of a Robert Ludlum book)
>>
>>>: "Extensions are adding new features beyond what is defined in the 
>>>specification, but not using any provided hooks or other mechanisms in 
>>>the specification."
>>
>>The Skallian hypothesis would simply say "Extensions are new features 
>>beyond what is defined in the specification", not the rest of it.  The 
>>hooks part is logically deduced by the definition.  The hooks (at least 
>>the way I think of them, as GDPs and Escapes) are features specifically 
>>designed to allow additional functionality to be added.  These features 
>>already exist in the standard.  Using them would not be an 
>>extension.  The "hooks" are only one example.  The point is that if you 
>>design for extensibility, by including ways to do that, it's not an 
>>extension if you use the pre-defined ways (features).  However, if an 
>>implementation provides the same functionality by adding an additional 
>>feature, that's an extension.
>
>I very strongly disagree.
>
>It is contrary to common practice of the last couple decades -- it 
>directly contradicts the approach of most of the standards that I have 
>worked closely with, both W3C standards and others like ISO.  In fact, I 
>can't think of a standard (W3C or ISO) which provides hooks and 
>accordingly declassifies stuff in the hooks as extensions.


That's interesting because after I searched to see how extensions are 
defined, I looked in many of the standards that you worked with (e.g., CGM) 
and found that the term "extensions" was not defined. Without a definition, 
extensions (like beauty) is in the eyes of the beholder.  Which standards 
that you worked with, especially one that provides hooks, explicitly 
defined extensions (especially wrt to the hooks.)?

>Specifically, the assertion that an extension was not an extension, if the 
>standard provided hooks by which it is expressed ... this completely turns 
>on its head our notion (e.g. from CR SpecGL) that standards *should* 
>provide hooks for extensions, so that extensions can be recognized as such.

That is your interpretation.  I think your over reaching.  You had you 
impression of whether "hooks" allow extensions (your impression)  or 
obviate the need for them if used (my impression) and I had mine.  In CGM, 
I always believed GDPs and Escapes were not extensions - you obviously 
believed the opposite.  However, if you look in the CGM standard, it 
doesn't mention it one way or the other. So different people came to 
different conclusions.  That's not common practice. That's your opinion. 
Why is the hook an "extension" if the hook is a feature provided and it is 
used?

> From an interoperability perspective (which is the one we should care 
> about), here is the key characteristic of an extension:
>
><It> is an extension if it is functionality that is not defined in the 
>base standard sufficiently fully that any implementation can handle it, 
>with no more information than contained in the base standard. It has 
>nothing to do with whether standards that allow extensions encourage use 
>hooks for valid content (or APIs, or whatever).


This is a quick switch of positions.  Weren't you always the one that 
wanted to use "feature", rather than "function"?


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