Extension/Extensibility examples in W3C Specifications

Lynne & al.

I went through a few specifications to find examples of "extension  
mechanisms".

* XHTML Modularization [1]

-> Modularization helps extensibility
	"""Modularization also allows for the extension of XHTML's
	layout and presentation capabilities, using the extensibility
	of XML, without breaking the XHTML standard. This development
	path provides a stable, useful, and implementable framework
	for content developers and publishers to manage the rapid
	pace of technological change on the Web."""

The mechanism for extensibility is basically defined by rules of  
conformance. XHTML Modularization defines the notion of a family. You  
belong to the family if you respect certain criterias which are defined  
in "3.3. XHTML Family Module Conformance " [3], you have in fact a

-> 1st: You define the extension by using W3C Technonologies
	=> i.e. XML DTD or XML Schema. (exit RelaxNG it seems)
-> 2nd: The extension is defined with a unique identifier.
	=> Here the naming rules are defined
-> 3rd, 6th: The features are uniquely recognizable
	=> Here unique prefixes or a similar method
	=> Unique namespace for defined modules
-> 4th: The features are clearly described and documented.
	=> Here syntactic and semantic requirements
-> 5th: An extension never override things which are already defined.
	=> Though they seem to soften it a bit by authorizing similar things  
if it has its own namespace, for example.

So an extension is
	an addition to the technology
	which is uniquely identifiable
	and do not redefine behaviour of the technology it extends
	and can have some organization and naming constraints defined by the  
technology it extends.

They also give examples of DTD implementations

And I have realized, that in [3], there's a normative section which is  
not written!!!

[1] http://www.w3.org/TR/2001/REC-xhtml-modularization-20010410/
[2]  
http://www.w3.org/TR/2001/REC-xhtml-modularization-20010410/xhtml- 
modularization.html#a_schema_developing
[3]  
http://www.w3.org/TR/2001/REC-xhtml-modularization-20010410/xhtml- 
modularization.html#s_conform_module


* Behavorial Extension to CSS [4]

I don't know what will become of this document (The last working draft  
is from 1999à but it's interesting to read. The document proposes to  
use scripting feature driven by CSS selectors. It defines an extension  
on CSS, redifining or copying another W3C technology (DOM).

For example, proposition of a
	@script "text/javascript";
instead of the traditional (X)HTML
	<script type="text/javascript" />

The benefits envision here is to make it reusable for any kind of XML  
documents, but in a sense it could be done with a:
	<xhtml:script type="text/javascript" />


The question illustrated is a technology by an extension mechanism can  
redefine another technology.
	Can CSS redefines some behaviour of XHTML, DOM?
	Can SOAP redefines some property of HTTP?
	etc.

[4] http://www.w3.org/TR/1999/WD-becss-19990804


* CSS-3

I can't find the document right now which defines CSS-3 extensibility,  
but basically the first draft which has been given to me was defining a  
very clear mechanism (scheme) to name the new selectors.

	-vendor-name-features
	
	+ minus to start
	+ vendor identification
	+ name of the features

But if I remember they were no requirements that the documentation  
explaining, describing the feature was published. Maybe there should be  
a clear policy about that too.
	I see few minor caveats:
	+ vendor identification, name conflict: It will not happen often, but  
it might happen.
	+ if we ask for a clear description of the created extension, where  
this documentation should be?
	Usually we have the requirements to put in a clear and *stable* place  
(Cool URIs don't break), though it's not often the case. Should we  
encourage people to send them to www-archive? or to have a kind of Web  
repository like www-archive.


I will continue to try to find new examples.
	

-- 
Karl Dubost - http://www.w3.org/People/karl/
W3C Conformance Manager
*** Be Strict To Be Cool ***

Received on Monday, 3 May 2004 18:20:28 UTC