Re: SpecLite: extensions

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?


Not really.  Conformant implementations conform - and thus that is 
conformance.  They are really the same thing.


>>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.)

It's true that the term "the ability" is not the correct term.  I would 
prefer "the incorporation of functionality beyond what is defined in the 
specification ("by an implementation" is implied but we should say that 
explicitly)


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

Correct.  Extensions have always applied to implementations.  Functionality 
incorporated into a profile, above and beyond the base standard, is not an 
extension.  It's a profile that doesn't conform to the base standard.


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

As I said, my beef is the use of the term "extensibility" restricted to 
extensions. Extensibility is a general term and is applied to anything.

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

Yes, yes, yes.


>>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.)

Then it used the term differently than anything I've seen before.

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


But we don't have to use it in the QA framework documents.

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

Again, I defined extensions above and I think we should eliminate 
"extensibility"

>Cheers,
>-Lofton.