Extensibility Web Arch / QA Extensions

Dear TAG Members,

It seems the Extensibility [1] prose proposed by the TAG have  
differences with the Extensions [2] prose given by the QA documents.

So we are trying here to work out if your notion of extensions is the  
same than the one mentionned in the QA Framework. In the QA Framework,  
we defined "An extension to a specification is a mechanism to  
incorporate functionality beyond what is defined in the specification."

Extensions lead to interoperability problems, most of the time.
To avoid these problems the *framework* which authorizes extensions to  
a given technology MUST be clearly and unambiguously defined. So, the  
more flexible you want to be with your technology, the stricter you  
have to be for the conceptual framework of your technology. It made it  
a lot more difficult to design for the WG.

The Web Architecture document doesn't specify what extensibility is ?  
Extensibility and extensions are two different things.

	* Extensibility is the ability of a technology to accept extensions in  
a defined way. If the extensibility mechanism is not defined, the  
technology is not extensible.
	* Extension is an additional feature to a technology which gives the  
possibility to extend the behaviour of the technology.

TAG
	"""
	* Good practice: Extensibility mechanisms
	Language designers SHOULD provide mechanisms
	that allow any party to create extensions
	that do not interfere with conformance
	to the original specification.
	"""

Extensibility is not to encourage. It doesn't mean you have to ignore  
the need for extensibility, but if you provide such a possibility for a  
technology, you have to be careful in the way you are doing it.

I would encourage the TAG to modify the Good Practice sentence to:

	"""
	* Good practice: Extensibility mechanisms
	When Language designers provide Extensibility
	mechanisms that allow any party to create
	extensions, they MUST provide a clear Extensibility
	Framework that does not interfere with conformance
	to the original specification.
	"""

For example, the QA Framework recommends to:

	"""
	The specification MUST state the conditions
	under which extensions are allowed and
	disallowed, and if allowed, MUST state:
		* the scope of the extensions,
		* their effect on conformance claims,
		* any limitations or restrictions on the
           use of the extension,
		* the rationale for allowing extensions by
           referencing use cases and/or  project
           requirements.
	"""

And
	"""
	* Prevent extensions from contradicting the specification.
	* Define a uniform mechanism to create an extension.
	* Require that extensions be published.
	"""

* Know/Unknown: How?

It would be good also to define what is an "unrecognized extension" or  
"unknown extension".
	1. Use only one term : unrecognized or unknown.
	2. When an extension is unrecognized or unknown?
	Just before you define that the Language designers *SHOULD* give  
extensibility mechanisms. But not that they MUST define it, definition  
which will give the opportunity to know if the extension is known or  
unknown.



[1] http://www.w3.org/TR/2003/WD-webarch-20031209/#pr-allow-exts
[2]  
http://www.w3.org/TR/2003/WD-qaframe-spec-20030912/guidelines- 
chapter#Gd-extensions


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