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

Re: SpecLite: extensions

From: Lofton Henderson <lofton@rockynet.com>
Date: Tue, 27 Apr 2004 23:28:52 -0600
Message-Id: <5.1.0.14.2.20040427230607.032dbbe0@localhost>
To: Mark Skall <mark.skall@nist.gov>
Cc: www-qa-wg@w3.org

At 08:33 PM 4/27/2004 -0400, Mark Skall wrote:
>At 04:01 PM 4/27/2004 -0600, Lofton Henderson wrote:
>>At 04:19 PM 4/27/2004 -0400, you wrote:
>>[...]
>>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.

Huh?  I'm sure that I must be misunderstanding your point here.  Because 
what I hear you saying is contrary to a significant and long-established 
body of practice.

How can a profile conform to the base standard?  A Class of Product 
conforms to some applicable conformance requirements of a base 
standard.  Typically a CoP is something like a generator or interpreter of 
a standardized format.  If, and only if, the base standard contains "Rules 
for Profiles", then a profile can conform or not to the base 
standard.  Otherwise the question "does profile conform to base standard" 
is meaningless.

I think you are confusing "a profile shall not contradict the base 
standard" with a broader notion of conformance of a profile to the base 
standard.  A profile can define and allow some extensions, and not 
contradict the base standard, and conform to the base standard.

Example.  ISO CGM has Rules for Profiles (RfP).  (These were added to ISO 
CGM around 1995, and have been considered by many to be an early example of 
good practice in the field).  The RfP define some terms and conditions 
(T&C) about extensions.  A profile may define and allow extensions, and 
still be conforming to RfP, if certain T&C are met.  WebCGM defines 
extensions and meets the RfP, therefore it conforms to the CGM base 
standard.  ATA does the same.  AECMA does the same.  Etc...


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

The terms are in common use in our own documents for 2+ years, and in the 
world at large as well (e.g., the citations I gave to WebArch).  IMO, it 
would be folly to try to ignore this.  This is like the glossary trying 
force the world, instead of precisely explain the world.  (Clearly I 
believe in the latter, but maybe that belief is not shared.)

>[...]
>Again, I defined extensions above and I think we should eliminate 
>"extensibility"

As you can tell, I strongly disagree with the latter.

Over and out,
-Lofton.
Received on Wednesday, 28 April 2004 01:30:50 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.30 : Thursday, 9 June 2005 12:13:15 GMT