Re: SpecLite: extensions

At 04:19 PM 4/27/2004 -0400, you wrote:

>>Sure.  Let it begin...
>>
>>Does anyone object to adopting Karl's definition(s), which I quoted below?
>>
>>-Lofton.
>
>I object (sounds like a courtroom).  I think we are really confusing the 
>issue.  I never liked the idea of confusing 2 terms that sound alike - 
>extensions and extensibility.

Sorta' like conformance and conformant, eh?

>However, if we're going to use them then the proposed definitions make no 
>sense to me.

Then propose two alternative ones so that we'll have something specific to 
discuss.

Whether or not you like Karl's new one, I think you have to admit that our 
current definition from the draft SpecExtensions module (and SpecGL) is 
muddled:  " Extension: The ability to incorporate functionality beyond what 
is defined in the specification. The ability to extend or enhance the 
specification".  The phrase "the ability to" seems to me to turn it into 
"extensibility".  (See your own definition 2 sentences later.)

>We all know what extensions are - they are additional functionality (or 
>additional features, I really don't care which term we use), provided by 
>an implementation, above and beyond what's specified in a standard or rec.

Why is the limitation of "an implementation" important?  Why can't it be 
additional functionality that is added to a technology definition, e.g., by 
a profile?  How about the 'visibility' extension defined by the WebCGM 
profile.  Is that not an extension until it's implemented.

>However, extensibility typically refers to the ability of a document (or a 
>technology or process or . . .) to be extended (e.g., by providing "hooks" 
>or other placeholders).

Sounds a lot like the first sentence of Karl's, "* Extensibility is the 
ability of a technology to accept extensions in
a defined way".  So what's your beef with his proposed definition.  The 2nd 
sentence?

>This ability or capability to be extended has nothing to do with extensions,

Karl's proposed definition does not have "ability".  That is in our current 
one.  So you agree that aspect of our current one is wrong?

>which are additional functionality/features in an implementation.

I disagree with your limitation there.  I work on profiles all the 
time.  Profiles sometimes define extensions to the base 
standards.  Implementations implement extensions (maybe of their own 
definition).  (The ISO CGM "Rules for Profiles" in fact make a systematic 
treatment of extensions (private), extensions (semi-standard published), etc.)

>A technology cannot be extensible to allow for extensions because 
>extensions (by definition) are provided by an implementation, not a 
>technology. Extensibility and extensions are 2 separate concepts which 
>happen to be derived from the same root.

I agree that they are two separate concepts.  I have some real problems 
with your definition of "extensions".


>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.  Both are used in:

http://esw.w3.org/topic/ExtensibilityGoodOrBad
http://www.w3.org/TR/qaframe-spec/guidelines-chapter#Gd-extensions
http://www.w3.org/TR/2003/WD-webarch-20031209/#ext-version
http://esw.w3.org/topic/ExtensionSpeclite
...etc...

We have been seriously criticized for the coverage (and quality) of our 
definitions and glossary sections.  We have promised in issue resolutions 
to do better.  Therefore we must include definitions all terms that we 
use.  Especially ones like this pair, where as we see there are already 
serious disagreements about what they mean.

Bottom line:  Propose two alternate definitions.

Cheers,
-Lofton.