There are many different systems for exchanging texts in languages, such as SQL, Java, XML, ECMAScript, C#. We will briefly describe some key refinements to our lexicon for XML. An XML language has a vocabulary that may use terms from one or more XML Namespaces (or none), each of which has a namespace name. An XML language is an identifiable set of vocabulary terms with defined XML syntactic and semantic constraints. By XML language, we mean the set of elements and attributes, or instances, used by a particular application. The Name Language - consisting of name, given, family terms - has a namespace for the terms. We use the prefix "namens" to refer to that namespace. The Name Language could consist of terms from other vocabularies, such as Dublin Core or UBL. These terms each have their own namespaces, illustrating that a language can comprise vocabularies from multiple namespaces. An XML Namespace is a convenient container for collecting terms that are intended to be used together within a language or across languages. It provides a mechanism for creating globally unique names.

We shall use the term instance when speaking of sequences of characters (aka text) in XML. An instance is a specific, discrete Text in XML format. Documents are instances of a language. In XML, they must have a root element. A name text might have a name element as the root element. Alternatively, the name vocabulary may be used by a language such as purchase orders. The purchase order texts may contain name elements. Thus instances of a language are always part of a text and also may be the entire text. XML instances (and all other instances of markup languages) consist of markup and content. In the name example, the given and family elements including the end markers are the markup. The values between the start and end markers are the content. An instance has an information model. There are a variety of data models within and without the W3C, and the one standardized by the W3C is the XML infoset.

The XML related terms and their relationships are shown below

Ultimately, there are different kinds of XML languages. The versioning approaches and strategies that are appropriate for one kind of language may not be appropriate for another. Among the various kinds of vocabularies, we find:

This is by no means an exhaustive list. Nor are these categories completely clear cut. MathML can certainly be used standalone, for example, and languages like SVG are a combination of standalone, containers, and mixtures.

The following names would be valid:

The 2^nd example shows all the components in the same new namespace. The 3rd and 4^th example show an additional middle element in 2 different namespace names. The 3rd example comes from a namespace name that is in the same domain as the name element’s new namespace name. One reason for 2 namespaces is to modularize the language. The 4^th example shows a namespace name from a different domain for the middle. It is probable that the mid:middle was created by the name author, and the middiffdomain:middle was created by a 3rd party.

This strategy has the impact of potentially and generally resulting in incompatible changes. When an older consumer receives the new texts in the new namespace, most of the software will break, such as performing schema validation without the new schema. Achieving forwards compatibility requires careful selection of technologies, such as XPath expressions that are namespace agnostic. The effect of the change being an incompatible change is the design goal of some systems that have adopted this strategy

In this strategy, the following names would be valid:

The 2^nd and 3^rd example show an additional middle element in 2 different namespace names. The first middle, the 2^nd example, comes from a namespace name that is in the same domain as the name element’s namespace name. The 3^rd example shows a complete different namespace name for the middle. It is probable that the mid:middle was created by the name author, and the middiffdomain:middle was created by a 3rd party.

In this strategy, the following names would be valid:

The 2^nd example shows the use of the optional middle name in the name namespace. The 3^rd and 4^th example show an additional middle element in 2 different namespace names. The first middle, the 3rd example, comes from a namespace name that is in the same domain as the name element’s namespace name. The 4^th example shows a complete different namespace name for the middle. It is probable that the mid:middle was created by the name author, and the middiffdomain:middle was created by a 3rd party.

Using a version identifier, the name instances would change to show the version of the name they use, such as:

The last two examples show that the middle is now a mandatory part of the name. This is indicated by just the version number or a new namespace plus version number.

A significant downside with using version identifiers is that software that supports both versions of the name must perform special processing on top of XML and namespaces. For example, many components “bind" XML types into particular programming language types. Custom software must process the version attribute before using any of the “binding" software. In Web services, toolkits often take SOAP body content, parse it into types and invoke methods on the types. There are rarely “hooks" for the custom code to intercept processing between the “SOAP" processing and the “name" processing. Further, if version attributes are used by any 3rd party extensions—say mid:middle has a version—then the schema cannot refer to the correct middle.

Using a version identifier, the name instances would change to show the version of the name they use, such as:

The 2^nd example shows that the middle is an optional part of the name. The last example shows that the middle is a mandatory part of the name.

A downside with using new namespace names is that some tools, like XPath, can be harder to use in the face of new namespace names. Software that extracts the given and family name based upon the expanded name will often break if a new namespace name is used.

The various schema languages have a variety of defined mechanisms to indicate extensions that are incompatible. For example, XML Schema provides Type Extension and Substitution Groups. These mechanisms are described in Part 2.

Using XML Schema 1.0, the name owner might like to write a schema such as:

The next version of the schema, with middle name added, might look like

This schema is illegal because the middle in the 2nd name namespace and the wildcard with ##other are non-deterministic. More on non-determinism in the next strategy. An alternative is to not have the wildcard at all, and rely upon subtyping for extension. But this prevents any kind of compatible evolution as both sides must have the new schema to understand the type. There language designer has to choose between allowing compatible extensibility/versioning OR incompatible extensibility when subtyping is used.

Because of the type extension determinism problem, the language designer cannot re-use the existing name definition. They must create a new schema without any reference to the previous schema.

The new namespace for all components does not allow compatible evolution by the language designer, unless they choose to put new components in a new namespace which is strategy #2. Additionally, the version 2 schema cannot re-use the existing type definition.

We previously saw how re-use by importing and extending schemas with wildcards is not possible. In this strategy, the schema designer attempts to insert the new extension in the existing schema definition, like:

However, the determinism constraint of XML Schema, described in more detail later, prevents this from working. The problem arises in a version when an optional element is followed by a wildcard. In this example, this occurs when an optional element is added and extensibility is still desired. This is an ungentle introduction to the difference between extensibility and versioning. An optional middle name added into a subsequent version is a good example. Consumers should be able to continue processing if they don’t understand an additional optional middle name, and we want to keep the extensibility point in the new version. We can't write a schema that contains the optional middle name and a wildcard for extensibility. The previous schema schema is roughly what is desired using wildcards, but it is illegal because of the determinism.

The author has 4 options for the v2 schema for name and middle, listed below and detailed subsequently:

If they leave the middle as optional and retain the extensibility point, the best schema that they can write is:

This is not a very helpful XML Schema change. The problem is that they cannot insert the reference to the optional mid:middle element in the name schema and retain the extensibility point because of the aforementioned Non-Determinism Constraint.

The core of the problem is that there is no mechanism for constraining the content of a wildcard. For example, imagine that ns1 contains foo and bar. It is not possible to take the SOAP schema—an example of a schema with a wildcard - and require that ns1:foo element must be a child of the header element and ns1:bar must not be a child of the header element using just W3C XML Schema constructs.   Indeed, the need for this functionality spawned some of the WSDL functionality.

They could decide to lose the extensibility point (option #2), such as

This does lose the possibility for forwards-compatible evolution.

The final option, #3, is adding a required middle. They must indicate the change is incompatible. A new namespace name for the name element can be created. This is essentially strategy #1, new namespace for all components.

The downsides of the 3 options for new components in new namespace name(s) design have been described. Additionally, the design can result in specifications and namespaces that are inappropriately factored, as related constructs will be in separate namespaces.

The "new components in new namespace(s)" versioning strategy implies a rule for namespaces of:

Allow Extensions in Other Namespace rule: The extensibility point SHOULD at least allow for extension in other namespaces.

The rule for allowing extensibility:

Full Extensibility rule: All XML Elements SHOULD allow for element extensibility after element definitions, and allow any attributes.

It is possible to create Schemas with additional optional components. This requires re-using the namespace name for optional components and special schema design techniques. The re-using namespace rule is:

Re-use namespace names Rule: If a backwards compatible change can be made to a specification, then the old namespace name SHOULD be used in conjunction with XML’s extensibility model.

It is important to note that that a new namespace name is not required whenever a specification evolves - strategies #1 and #2 - but rather a new namespace name can be required only if an incompatible change is made. Strategy #1 uses a new namespace for all existing components and any additions, Strategy #2 uses a new namespace for all additions. Strategy #3 re-uses namespaces for compatible extensions.

New namespaces to break Rule: A new namespace name is used when backwards compatibility is not permitted, that is software MUST break if it does not understand the new language components.

Earlier examples showed that it is not possible to have a wildcard with ##any (or even ##targetnamespace) following optional elements in the targetnamespace. The solution to this problem is to introduce an element in the schema that will always appear if the extension appears. The content model of the extensibility point is the element + the extension. There are two styles for this. The first was published in an earlier version of this Finding in December 2003. It uses an Extensibility element with the extensions nested inside. The second was published in July 2004, then updated on MSDN. It uses a Sentry or Marker element with extensions following it.

A name type with extension elements is

Because each extension in the targetnamespace is inside an Extension element, each subsequent target namespace extensions will increase nesting by another layer. While this layer of nesting per extension is not desirable, it is what can be accomplished today when applying strict XML Schema validation. It seems to at least this author that potentially having multiple nested elements is worthwhile if multiple compatible revisions can be made to a language. This technique allows validation of extensions in the targetnamespace and retaining validation of the targetnamespace itself.

The previous schema allows the following sample name:

The namespace author can create a schema for this type

The advantage of this design technique is that a forwards and backwards compatible Schema V2 can be written. The V2 schema can validate documents with or without the middle, and the V1 schema can validate documents with or without the middle.

Further, the re-use of the same namespace has better tooling support. Many applications use a single schema to create the equivalent programming constructs. These tools often work best with single namespace support for the “generated" constructs. The re-use of the namespace name allows at least the namespace author to make changes to the namespace and perform validation of the extensions.

An obvious downside of this approach is the complexity of the schema design. Another downside is that changes are linear, so 2 potentially parallel extensions must be nested rather than parallel.

Using a version identifier, the name instances would change to show the version of the name they use, such as:

The last example shows that the middle is now a mandatory part of the name. As with Design #2, the schema for the optional middle cannot fully express the content model. A schema for the mandatory middle is

A significant downside with using version identifiers is that software that supports both versions of the name must perform special processing on top of XML and namespaces. For example, many components “bind" XML types into particular programming language types. Custom software must process the version attribute before using any of the “binding" software. In Web services, toolkits often take SOAP body content, parse it into types and invoke methods on the types. There are rarely “hooks" for the custom code to intercept processing between the “SOAP" processing and the “name" processing. Further, if version attributes are used by any 3rd party extensions—say mid:middle has a version—then the schema cannot refer to the correct middle.

A schema for a Must Understand flag is provided below:

An example of an instance of a 3rd party indicating that a middle component is an incompatible change:

Another option for indicating mandatory requirements is allowing extension authors to use other schema mechanisms for extending the main type, such as type extension. The language designer allows for type extension, and they must specify that type extensions must be understood. Strategy #1 showed that it is impossible to write a schema that extends an existing type that has a wildcard with a new namespace'd component. Type extension does not enable extension authors to indicate incompatible extensions.

Another mechanism for extending a type in XML Schema is substitution groups. Substitution groups enable an element to be declared as substitutable for another. This can only be used for incompatible extensions as the consumer must understand the substitution type. Substitution groups require that elements are available for substitution, so the name designer must have provided a name element in addition to the name type.

Substitution groups do allow a single extension author to indicate that their changes are mandatory. The limitations are that the extension author has now taken over the type’s extensibility. A visual way of imagining this is that the type tree has now been moved from the language designer over to the extensions author. And the language designer probably does not want their type to be “hijacked".

However, this is not substantially different than an extension being marked with a “Must Understand". In either case—with the extensions higher up in the tree (sometimes called top-typing) or lower in the tree (bottom-typing)—a new type is effectively created.

The difference is that there can only be 1 element at the top of an element hierarchy. If multiple mandatory extensions are added, then the only way to compose them together is at the bottom of the type because that is where the extensibility is.

Substitution groups do not allow a language designer and an extension author to incompatibly change the language as they end up conflicting over what to call the name element. Thus substitution groups are a poor mechanism for allowing an extension author to indicate that their changes are incompatible. A Must Understand flag is a superior method because it allows multiple extension authors to mix their mandatory extensions with a language designer’s versioning strategy. Hence language designers should prevent substitution groups and provide a Must Understand flag or other model when they wish to allow 3rd parties to make incompatible changes.

In some cases, a language does not provide a Must Understand mechanism. In the absence of a Must Understand model, the only way to force consumers to reject a message if they don’t understand the extension namespace is to change the namespace name of the root element, but this is rarely desirable.