Re: Extension/Extensibility examples in W3C Specifications

Ideally technology + its extension is conformant with the base spec

e.g.
XHTML + PoetryML is conformant XHTML

(I suspect that is not the case, but it is an ideal)

A hypothetical XHTML spec could suggest that user agents, when they come 
across an extension they do not understand take some fall-back 
behaviour, but recognise the input as *legal* rather than *illegal* (Of 
course some users may wish to reject extensions)

Jeremy

Karl Dubost wrote:

> 
> Le 04 mai 2004, à 11:20, Dominique Hazaël-Massieux a écrit :
> 
>>>  One possibility Lynne and I discussed is
>>> to just use "extensibility" and not use, or define, "extensions"
>>
>>
>> I think that extensibility is indeed a better term to describe what we
>> want to talk about in SpecGl ; that said, given that the term
>> "extensions" seems to give us troubles, it would be good to have the set
>> of definitions that the term "extension" covers, so as to reduce the
>> ambiguity later on.
> 
> 
> We have really to focus on the definitions and their meanings.
> 
> Everything in the world is extensible, or almost. It's particulary true 
> for a technology.
>     A technology is de facto extensible and can have extensions.
>     Therefore, the extensibility nature of a technology is true, all the 
> time.
> 
> Now we are working in the context of the W3C, a *standard organization*. 
> I really would like to stress this point. A technology at W3C is 
> something which has been, in the best case,  built with the 
> participation of W3C Members and public participation and a consensus.
> 
>     Technology LoveML is defined. You can be conformant or not to this 
> technology LoveML.
> 
> This mean that you respect certain criteria when you implement the 
> technology. These criteria are defined in a conformance section. The 
> LoveML WG has foresee that some people would like to develop specific 
> implementations with more features, more possibilities, but very 
> particular to a product or a specific market.
> 
> They decide to make LoveML extensible and so to create an extensibility 
> mechanism. They would like to avoid the mess between different products, 
> they would like to avoid to have interoperability problems. So they 
> develop a mechanism which makes possible to create extensions to LoveML 
> in a harmonious way. They define rules for that.
> 
>     Now let's dig a bit with a real example:
> 
> * XHTML 1.1 is an implementation of XHTML Modularization.
> * XHTML Modularization has a very strict framework to create other XHTML 
> Mod Modules in a conformant way.
> 
> It means you can designed for example a PoetryML Module for XHTML 1.1 
> without screwing XHTML 1.1, Let's call the final thing: "XHTML Poetry" 
> which is XHTML 1.1 + PoetryML Module.
> 
> The results are:
> 
> 1. You can NOT be conformant to XHTML Poetry per W3C Rules.
> 2. An external organization may have defined Conformance Rules to XHTML 
> Poetry (fine)
> 3. Your PoetryML Module is conformant to regards to the conformance 
> Rules of XHTML Modularization.
> 
> Conclusion:
>     Extensibility Framework gives the possibility to avoid 
> interoperability problems and to design extensions to spec which are 
> conformant to this extensibility framework.
>     It doesn't mean that the technology + its extension define a new 
> conformance set.
> 
> 
> ===> It's my way of seeing things and it's the whole purpose of a 
> standard organization, IMHO. To have a minimal set of requirements which 
> are interoperable.
> 
> Open to debate ;)
>

Received on Wednesday, 5 May 2004 03:59:46 UTC