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).

Must ignore: The agent ignores any content it does not recognize
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: address if extensions affect a conformance 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).