Different kinds of languages and different versioning strategies expose
different problems. Attempting to deploy a system that provides no versioning mechanism may put the burden of version "discovery" on consumers and my be impractical in anything except a closed system.
At the other end of the spectrum is an incompatible versioning approach which
is also problematic. "Incompatible" versioning is usually a very coarse-grained approach to
versioning. It often requires that all of the text must be understood and known by the consumer or the consumer will fault. It often establishes a single version identifier, such as a version number or namespace name, for an entire text. In many cases, a single version identifier is not an accurate representation of the "version" of the text, particularly when a text is composed of many sub-languages.
Consider a producer and a consumer exchanging texts of a particular language. Imagine that some future version of the language includes new texts in the language. Because producers and consumers are distributed, it may happen that an old consumer, one unprepared for the new text, encounters a newer text sent by a newer producer.
If incompatible versioning is used, old consumers will reject the new
text. However, if the versioning strategy allows the old
consumer to process the text even with the unrecognized content, it's quite possible
that other components of the system would adapt to the previous
behavior. In effect, the old system would ignore the new component
or provide some other default interpretation for it. For the producer, the result would be that the request is fulfilled,
though perhaps not taking into account the new features. For example, a request that results in a response may return a text of the language without the new component. In many
cases this may be better behavior than receiving an error. In particular, producers using the new language can be written to cope with
the possibility that they will be communicating with older consumers.
If the producer needs to require that the new text is understood,
then it can change the language in a way to indicate that the new text is not considered optional, aka incompatible.
Often, what is needed is some sort of middle ground solution where compatible and incompatible changes are supported, and these are discussed in the sections on compatible and incompatible.
2.1.1 Identifying Languages
As part of a strategy for language design, the language may or may not include version identifiers in the text. One design is that the texts do not contain any version identifiers and all texts are intended to be backwards and forwards-compatible. [CSS] is an example of this strategy as there are no version identifiers in the stylesheets and the language follows the subsequently described rules for ensuring backwards and forward-compatible evolution. There is a benefit of no version identifiers in the text because it forces the language designer(s) to design and plan for compatible evolution as they cannot introduce an incompatible change and "simply" update the version identifier. In fact, the CSS language designers have constrained themselves to only evolve CSS compatibly with previous version(s).
The design of putting version identifiers in the text is very common. It is may be beneficial and necessary for a receiver to determine which version(s) of a language specification can be used to correctly interpret a given text and know this early in the text. This is often done by providing an identifier of the version early in a text, such as a version number or structure such as an XML Namespace.
Regardless of any particular technologies chosen, the language should have a version identification strategy.
Good Practice
Language specifications should specify the meaning of the structure of any version identifiers in texts with respect to compatible or incompatible evolution of the language.
The difficult, important, and often overlooked part of a version identification strategy is specifying the meaning and interpretation when a consumer encounters a version identifier it does not know about. A typical problem with version identifiers is that it is unclear what is being identified with the version identifiers. The common misconception is that a version identifier, such as a number, indicates the version of the language used when producing the document. That may be true, but in many cases the version identifier is unusable for versioning because the language and/or software does not have sufficient provisions for versioning.
There are many possibilities for what a version identifier identifies. For a text that is potentially in many different versions of a language, and assuming versions are ordered, an identifier that is a number could be:
The latest version of the language the document is compatible with
The lowest version of the language the document is compatible with
The lowest version of the language that has all the features the language uses
The set of versions of the language the document is compatible with
Imagine that version 1 of a language for people's names defines a sequence of a first name, a last name, and other extensions; and version 2 defines a sequence of first, last, optional middle, and extensions. If a text contains a first and a last, should the identifier be version 1 or 2? The previous options yield answers of: 2, 1, 1, 1-2. If a name contains a first, a last, and a middle then the previous options yield answers of: 2, 1, 2, 1-2
The usual scenario is the document contains the version number of the latest version of the language that the producing application understands - scenario #1. Thus the "newest" version of the identifier is used, even if the document itself is valid under older versions of the language. This usually works fine if the producer and consumer are at the same version, or even if the consumer understands the older and the newer version. But forwards compatibility requires that a consumer that doesn't understand the newer version must somehow treat the document as if it was an older version. Approaches for using version identifiers to enable forwards compatibility is covered in 5 Forwards Compatible
As a side note, version identifiers are often used in protocols that exchange documents. One scenario is that the version number identifies the latest version of the language the document is compatible with and that the producer will understand when it becomes a consumer of a response document. In this case it is a protocol version identifier, not just a format identifier. HTTP is a good example. The HTTP specification says "The protocol versioning policy is intended to allow the sender to indicate the format of a message and its capacity for understanding further HTTP communication, rather than the features obtained via that communication." Because HTTP is a request-response protocol, the capacity for further HTTP communication is the crucial "version" information conveyed. Most documents that might have version #s do not fit that "future capacity" use case, they are just documents that do not belong to a protocol. There are cases where a document format is combined with a protocol, such as Atom. These combination protocol/format case are fairly rare and not generally applicable.
2.1.1.1 Version Numbers
Version identification is often done with a
decimal separating the major versions from the minor versions, i.e. "8.1",
"1.0". Often the definition of a "major" change is that it is incompatible,
and the definition of a "minor" change is that it is forwards- and/or backwards
- compatible. Usually the first broadly available version with a high probability of compatible future versions starts at "1.0". A
compatible version change from 1.0 might be identified as "1.1" and an
incompatible change as "2.0".
The version numbers can be contained in the texts, in the protocol messages containing the text, or the address for the protocol messages. Some examples are shown below:
<name version="2.0">
<given>Dave</given>
<family>Orchard</family>
</name>
<span class="fn20">Dave Orchard</span>
urn:nameschemev2:given:Dave:family:Orchard
<?XML version="1.1"?>
GET /name/123456789 HTTP/1.1
GET /name/v2/123456789/ HTTP 1.1
As previously mentioned, the version number may be only associated with the language specification is not part of any texts of the language.
It should be noted that associating version number changes with compatibility changes may be idealistic as
there abundant cases where this system does not hold. New major version
identifiers are often aligned with product releases, or incompatible changes
identified as a "minor" change. A good example of an incompatible change that used the traditional minor version identifier change is
XML 1.1. XML 1.0 processors cannot process all
XML 1.1 documents because XML 1.1 extended XML 1.0 where XML 1.0 does not allow
such extension.
Unfortunately, the strategy of texts containing version numbers often results in approaches that are very similar to
the incompatible approach. In many approaches, each language is given a version identifier, almost always a
number, that's incremented each time the language changes. Although
it's possible to design a system with version numbers that enables
both backward and forward compatibility - for example XSLT - typically
a version change is treated as if that the new language is not backwards
compatible with the old language.
Some efforts, such as HTTP, try to have the best of both worlds
by allowing for extensibility (in HTTP's case, via headers) as well as
version numbers that explicitly identify when a new version is
backwards compatible with an old version.
One argument in favor of version numbers is that they allow one to
determine what is a 'new version' and what is an 'old version'. But in
practice this is not necessarily true. For example, RSS had 0.9x, 1.x,
and 2.x versions that were all developed in parallel. In effect
the version numbers, even though they appear to be ordered, were simply
opaque identifiers. Using version numbers does not guarantee that
version 1+x has any particular relationship to version 1.
Version numbers can serve as a useful optimization for consumers. A version number in a text can provide a consumer with an early indication of the compatibility of changes so that the consumer will not process the text any further.
Version numbers typically work best when versioning and extending a language is done in a centralized and linear manner. The makeup of each version can then be consistent and well described.
2.1.1.2 XML Namespaces
There are many cases where decentralized and non-linear versioning is desired. The desire for decentralized and non-linear versioning and extensibility was a large motivator for XML and for XML Namespaces. The self-describing and extensible nature of XML markup, and the addition of XML
Namespaces, provides a framework for developing
languages that can evolve in a decentralized manner. XML Namespaces
[ XML Namespaces 1.0] provide a mechanism for associating a
URI with an XML element or attribute name, thus specifying the
language of the name. This also serves to prevent name collisions.
There are a variety of strategies involving namespaces for version identification. They range from: using a new namespace for every version of the language, even minor or compatible changes; to using a new namespace only for new parts of a language that are compatible additions; to no new namespaces ever. There are costs and benefits to each strategy. For example, using a new namespace for every version of a language often involves breaking any software that is namespace dependent such as XPath expressions. These strategies, including XML and XML Schema samples is provided in [Versioning XML including XML Schema]