SpecLite: extensions

The following is an expansion of text for the Extension section of 
SpecLite.   Details, especially examples are needed. Additionally, 
normalization of our headings, e.g., Principle, good practice, etc. needs 
to be done.

Headings for this text are as follows:
General Heading - introducing the section:  Planning for Extensions
Principle = requirement
Good Practice = recommendation

As always, comment are appreciated, suggested text appreciated even more.

And, now for the text................................

Planning for Extensions

Extensions incorporate functionality beyond what is defined in the 
specification.  Extensions provide implementers the ability to include 
functionality that they consider to be required by their customers.  It 
also provides a way to ‘test-drive’ new functionality that may migrate into 
future versions of the specification.

Extensions can compromise interoperability if there are too many 
differences between implementations.  Planning for the extensibility of the 
specification can mitigate this affect by providing a defined structure and 
scope of the extension.  Extensibility is not free  but with good planning, 
the long term benefits may be worth the cost.

PRINCIPLE 1: Design your technology for extensibility

Some specifications are explicitly designed to allow extensions by 
providing a mechanism for any party to create extensions.  Providing a 
uniform mechanism or hook will help to ensure extensions are defined in a 
consistent manner leading to predictable handling of extensions  their 
recognition as such and the appropriate actions to take.  By designing for 
extensibility, there is less chance that extensions will interfere with 
conformance to the original specification and a better chance at achieving 
interoperability.

Examples of technologies that are explicitly designed to allow extensions 
include:  extensibility models in CSS, XSLT 1.0, and SOAP), user agent 
plug-ins.

How:  Technology and application needs will dictate the best strategy for 
enabling extensions.
Examples of mechanisms.
Templates/Tools? Probably not.

Good Practice:  Define error handling for unknown extensions
(@@is this only applicable to agents?)
When defining extensibility, include error handling for how an agent 
handles an extension it does not know how to interpret.  There are 
typically two approaches: (WebArch 
http://www.w3.org/TR/2003/WD-webarch-20031209/#pr-unknown-extension).
1.      Must ignore: The agent ignores any content it does not recognize
2.      Must understand: The agent treats unrecognized markup as an error 
condition.

A good way to handle these two approaches is to have a way in the syntax to 
distinguish which behavior is expected from the agent, e.g., mustUnderstand 
attribute in Soap 1.2
http://www.w3.org/TR/2003/REC-soap12-part1-20030624/#soapmu

Applicability: Extensible specifications such as languages and 
protocols.  Unlikely candidates include: content specifications (?) ????

Related Reference: TAG’s webarch. 
http://www.w3.org/TR/2003/WD-webarch-20031209/

PRINCIPLE 2: Address extensions in the conformance section
It should be clear to the reader whether or not extensions are allowed and 
under what circumstances this holds true.   Make known the scope and 
applicability of allowed extensions as well as any constraints or 
limitations.  This provides implementers as well as users a level of 
expectation and understanding, thus fostering interoperability.

Good Practice: declare whether or not extensions are allowed.
This doesn’t have to be complex, it may be a simple statement (e.g., 
extensions are not allowed) or implied by the inclusion of an extension 
mechanism.  The statement is usually associated with the conformance clause.

Disallowing extensions for any part of the specification is called strict 
conformance.

How?  Wording in the specification to address extensions
- Extension section  need examples
- Conformance statements  need examples
- Conformance claims  need examples

Good Practice: Prevent extensions from breaking conformance
Extensions must not contradict or negate conformance to the specification. 
If it conformed without the extension, conformance should hold true with 
the extension.

How: Include statements in the specification such as:
·       Each implementation must fully support all required functionality 
of the specification exactly as specified.
·       The use of extensions must not contradict nor cause the 
non-conformance of functionality defined in the specification.
·       Extensions must follow the principles and guidelines of the 
specification they extend; that is, the specifications must be extended in 
a standard manner.

Good Practice: indicate affect of extensions on claims.
If an implementation contains extensions, does this change the conformance 
claim?  Are the extensions part of the claim, ignored in the claim, 
disqualify the implementation from making a claim?


------------------------------
GLOSSARY Definitions:
Extension:  The ability to incorporate functionality beyond what is defined 
in the specification.   The ability to extend or enhance the specification.
Extensible:  The ability of a specification to accept extensions in a 
define way.  A specification is extensible if it provides a mechanism for 
any party to create extensions
Strict Conformance: conformance of an implementation that employs only the 
requirements and/or functionality defined in the specification and no more 
(i.e., no extensions to the specification are implemented).