Re: SpecLite: extensions

I like the definition of Extension that is in SpecGL
Extension: extension to a specification is a mechanism to incorporate 
functionality beyond what is defined in the specification.
(and dropping the additional stuff I added from WebArch - "The ability to 
extend or enhance the specification")

However, I would like to keep Extensibility, since I believe that this is 
the aspect of extensions that should be addressed in a specification.  As I 
said during the previous telecon - SpecLite should focus on the 2 things 
that editors have control of in a specification -
1. whether or not to put hooks into the spec to allow for extensions, thus 
making the spec extensible.
2. what can be said in a conformance claim -

Thus, I would like a definition for extensibility and proposed
Extensible: The ability of a specification to accept extensions in a define 
way. A specification is extensible if it provides a mechanism for any party 
to create extensions

I welcome modification to this, it is awkward. Perhaps, Mark and I can work 
on this.

--Lynne

At 04:01 PM 4/27/2004 -0600, Lofton Henderson wrote:
>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.