Extension/Extensibility examples in W3C Specifications:

The following is my attempt at summarizing a very interesting and 
informative discussion on extensions/extensibility and organize it in some 
way, so that we can incorporate it in the rewrite of the Specification 
Guidelines (SpecLite).   Please let me know where I've misrepresented 
something or just got it wrong as well as helping to add more detail and 
examples.   Additionally, I've indicated questions using @@.

1.  Definitions:  There is no clear definition of extension or 
extensibility, although both terms are used and seem to be understood 
within the context of their use.  They are tied closely to their (base) 
specification and vary as to the specificity of their meaning, use, 
invocation, etc.  However, there are characteristics that apply and a 
general definition can be derived.
Extension: characteristics that seem to always be true
  - additional feature (@@functionality?) to the specification.
  - does not break/negate the base specification
@@Are the following always true?
  - does not redefine existing technology (counterexample: CSS- By 
providing alternatives to another technology (@@is this true?)
- non-standardized functionality or capability beyond the scope of the 
specification. (counterexample: ??)

Therefore, general definitions:
a) Extension is the incorporation of additional features, beyond what is 
defined in the specification.

b) Extensibility is the ability of a specification to accept extensions in 
a defined way.  A specification is extensible if it provides a mechanism 
for any party to create extensions that do not interfere with conformance 
to the specification.

2.  Reasons for designing extensibility into a specification
- there will be extensions, it is inevitable.
- to accommodate the changing technology and information on the Web
- provides a stable, useful, framework to manage the rapid pace of 
technology change
- 'test drive' new functionality that may migrate into future specifications
- provides a consistent manner, leading to predictable handling of extensions
- less change for extension to interfere with conformance to the 
specification and a better change for achieving interoperability.

3.  Planning for extensibility
- depends on the specification and the technology.
- can be included as a provision or feature in the specification (example: 
XSLT, WSDL, others?)
- can be based on other specifications (example: CC/PP based on HTTP Ext. 
Framework, Owl's semantic extensions of RDF)
- can be a specification only about extensibility of the technology 
(example: Component Extension (CX) API, HTTP Extension Framework, XHTML 
Modularization?)

4. What is being extended
- the technology defined by the specification (example: XSLT, WSDL, others?)
- another technologies (RDF+OWL where OWL adds additional constraints, others?)
@@Where does XHTML Modularization fit? Where does CSS-3 fit?

5.  Different mechanisms.
Again technology and application dictates the best strategy and mechanism.
- mechanisms take different forms:
   -- conformance criteria/rules (XHTML),
   -- framework (HTTP ext framework, XHTML Mod),
   -- techniques (XSLT, WSDL)
@@ is this helpful?  is it correct?  Are there other mechanisms?

6.  Additional items
- error handling  how to handle unknown extensions (@@ does this apply to 
everything or just agents? )
- unique identifiers and declarations indicate extensions (HTTP ext 
framework, CC/PP) (@@ are there are examples of this?)

Thank you to all who have shared their knowledge, examples, and comments. I 
welcome all and any additional comments, examples, draft text, etc.
--Lynne

Received on Thursday, 6 May 2004 09:54:18 UTC