The primary motivation for allowing instances of a language to be extended is to decentralize the task of designing, maintaining, and implementing those extensions. It means that senders and receivers can implement changes without seeking explicit approval from the language owner. Consider the effort that the HTML Working Group put into modularity of HTML. Without some decentralized process for extension, every single variant of HTML would have to be called something else or the HTML Working Group would have to agree to include it in the next revision of HTML.

Allow Extensibility: Languages designers SHOULD create extensible languages.

HTML 1.1, 2.0, and 3.2 are examples of extensible languages. They allow for additional elements and attributes to be in document instances that are not defined by the respective HTML DTD. HTTP is another example of an extensible language as it allows new header fields in HTTP messages.

Unfortunately, extensibility is not free. Providing hooks for extensibility is another requirement that must be factored into the costs of language design. Experience suggests that the long term benefits outweigh the costs.

Some changes make a language completely incompatible with previous versions. Changes can also be backwards and forwards compatible. Designing languages to support compatible changes reduces the cost of those changes.

In an open system, it's simply not practical to handle language evolution with universal, simultaneous, atomic upgrades to all of the software components. Existing senders and recievers outside the immediate control of the organization that's publishing a changed language will continue to use the previous version for some (possibly long) period of time.

Finally, it's important to remember that systems evolve over time and have different requirements at different stages in their life cycle. During development, when the first version of a language is under active development, it may be valuable to persue a much more aggressive, draconian versioning strategy. After a system is in production and there is an expectation of stability in the language, it may be necessary to proceed with more caution. Being prepared to move forward in a backwards and forwards compatible manner is the strongest argument for worrying about versioning at the very beginning of a project.

Controlling the evolution of a language relies on two assumptions:

In order for a schema to be extensible in the way described above, to allow new elements or attributes to be added without changing the schema, the schema must allow extension in any namespace. This brings us to the next rule for enabling a must ignore versioning strategy in XML languages:

Any Namespace: Every language SHOULD provide for extension in any namespace.

If one extreme position is not to allow any extensions at all, then the opposite extreme is to allow extension everywhere: in every content model and on every element. In practice, allowing extensions everywhere may not be cost effective. For many languages, it may be possible to identify the smallest units that can effectively be extended and simply allow extension at those points and above. Bear in mind however that the cost of failing to allow extension where it is eventually needed may be much higher than the cost of allowing it in more places than obviously necessary today.

It usually makes sense to allow extension in attributes as well.

Full Extensibility: All XML Elements that can allow attributes, ie ComplexTypes in XML Schema, SHOULD allow any attributes and any elements in their content models.

The corollary of extensibility in any namespace, including the language's namespace, is that a namespace does not identify a single version of a language or set of names. A namespace identifies a compatible set of names.

Namespace identifies compatible names: The namespace name SHOULD identify names that are compatible within the same namespace name.

Given that a namespace name is not for a single version of a language or set of names, it may be useful to identify the particular version. An example would be specifying in a policy statement the exact language supported by a software agent. This use of version identification could be considered each compatible "minor" version, with the namespace name identifying the incompatible versions.

Identify specific version with version attribute: The specific version of a set of names within a given namespace MAY be identified with a version attribute to differentiate between the compatible versions

The key value of providing extensibility as described above is that existing XML documents may be extended without having to change existing agents. In order to allow existing agents to process extensions, the extension model must also specify agent behaviour in the presence of extensions. For languages that are intended to be extensible, specifications SHOULD provide a clear processing model for extensions.

Provide Processing Model: Languages SHOULD provide a processing model for dealing with extensions.

Failing to provide a processing means that extensions, including compatible changes, are typically predictably usable, as the receiver will not behave predictably.

As an existing agent cannot know the intended semantics of a component that its never seen before there are realistically two options: ignore that component or generate an error. Both these models are at least predictable. However, the error processing model does not allow for extensibility or compatible changes. We propose, therefore, that agents must ignore elements and attributes they do not recognize.

For many agents, including most Web services, the most practical rule is: must ignore.

Must Ignore: Receivers MUST ignore any XML attributes or elements that they do not recognize in a valid XML document.

This rule does not require that the elements be physically removed; only ignored for most processing purposes. It would be reasonable, for example, if a logging agent included unrecognized elements in its log. There are cases where the elements should not be physically removed. An example is an agent that forwards the content to another receiver should preserve the unknown content.

HTTP 1.1 is an example of a language that specifies that receivers should ignore any headers that it doesn't understand. RFC 2616 says "Unrecognized header fields SHOULD be ignored by the recipient and MUST be forwarded by transparent proxies."

agents must deal carefully with the ignored elements, especially if any of them are counted or if the agent makes use of information about their position.

There are two broad types of languages relating to dealing with extensions. These two types are presentation or document and data oriented agents. For data oriented agents, such as Web services, the rule is:

Must Ignore Component and descendents: The Must Ignore rule applies to unrecognized elements and their descendents.

The purpose of ignoring the descendents is that the descendent components are usually semantically coupled with the ancestor, and the meaning of the descendents cannot be inferred without the ancestor. For example, an address component that is understood but is a child of an unknown purchase order component has an unknown semantic on it's own.

Document oriented languages need a different rule as the agent will still want to present the content of an unknown element. The rule for document oriented agents is:

Must Ignore Component only: The Must Ignore rule applies only to unrecognized elements

This retains the descendents of the ignored container element, such as for display purposes.

An example of the Must Ignore Component only is HTML 1.1, 2.0 and 3.2. They specify that any unknown start tags or end tags are mapped to nothing during tokenization.

In order to accomodate big bang changes when they are needed, the must ignore rule is not expected to apply to the root element. If the document root is unrecognized, the entire message must be rejected.

The principles above distribute the notion of versioning into the components that constitute messages. Changes that are compatible with the extension mechanism do not require a namespace change.

Re-use Namespace Names and Element Names: If a backwards or forwards compatible change is made to an element definition by the owner of the element's namespace, then the old namespace name and element names SHOULD be used in conjunction with the extensibility model.

As indicated above, some changes simply introduce incompatibility. There are a few distinct types of backwards incompatible change:

Only the owner of a namespace can change (ie. version) the meaning of elements and attributes in that namespace.

Only Namespace Owners Change Namespace: The namespace name owner is the only entity that is allowed to change the meaning of names in a namespace.

One interesting example of this is the use of the XML Schema data type namespace name. The XML Query Working Group received permission from the XML Schema working group and the domain owner (W3C) to augment the XML Schema data type namespace without changing the namespace name. In this case, the namespace name owner changed the meaning of its names by granting permission to another group.

There is a school of thought that says that every extension should be placed in a separate namespace; that after publication, no new names should be added to a namespace. If you hold that point of view then you may not feel that an extensibility element is necessary or desirable. In the previous example, that would mean that XML Query would require a new version of the XML Schema in order to use a single XML Schema data type namespace.

Another school of thought says that the maintainers of the language have a right to add new names to a namespace as they see fit. There are certain advantages associated with adding new names in the same namespace.

A namespace name owner will use the lifecycle of the namespace as one of the factors in determining whether to revise the namespace or not. Typically, the changes during development are not compatible changes. The author of namespaces that are under development will typically follow a "big bang" approach. This helps reduce the number of potentially buggy or immature implementations that are deployed. A W3C specification is a good illustrative example. It will probably change namespace names for each working draft. The Candidate Recommendation, Proposed Recommendation and Recommendation namespaces names should only be changed if compatibility is not achieved.