[SpecGL DRAFT] D3 - Principle: Address the extensibility topic inside specification.

Lynne, Yours to review ;)

D.3 Extensibility and Extensions

	Deal with the likelihood of extensions. Consider whether some parts of 
the specification will benefit from extensibility. If so, define a 
mechanism to allow for the extension.

	Address the extensibility topic inside specification.

	Extensions might be encouraged or discouraged by the Working Group. 
There is a benefit to address the value or danger of extensibility for 
the technology which is currently developed. Formalizing the position 
of the Working Group by a clear defined section and prose will remove 
ambiguities for the specification users about the possibility of 
developing extension or not.

	There are strong chances that developers will create extension to a 
specification, because they have specific needs which are not covered 
by the specification and that they have to develop in a private 
specific context.  Writing clearly how the extensions have to be 
developed is a necessity to avoid a few issues: interoperability 
problems, minimal support, harmonious future development.
	The WG may consider that the technology is complete, self-sufficient 
and don't need at all any extensions. In this case, it is necessary to 
write it clearly in the specification and to explain why the technology 
is not considered extensible. It might be just for the social benefit 
of the community to ensure a maximum interoperability.


	1. Create a section of your specification dedicated to the extensions 
	2. Call it Extensions
	3. Make a table of contents entry for it
	4. Address the following principles and good practices of this section

	(I'm offline now. I'll add a few examples)
	* CSS3 module: Syntax
	W3C Working Draft 13 August 2003
	The specification "CSS3 module: Syntax" has addressed the topic of 
extensions. It is clearly identified in the table of contents and 
there's a specific section for it.


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

Received on Tuesday, 22 June 2004 16:48:32 UTC