W3C home > Mailing lists > Public > www-qa-wg@w3.org > May 2004

Re: new version of SpecLite - Extensions

From: Lofton Henderson <lofton@rockynet.com>
Date: Fri, 07 May 2004 07:31:16 -0600
Message-Id: <>
To: Mark Skall <mark.skall@nist.gov>
Cc: www-qa-wg@w3.org
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 

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.

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.

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

Received on Friday, 7 May 2004 09:33:07 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:14:32 UTC