Version one dot what?

Dave Orchard muses once again on the topic of versioning. This time, he takes on the sub-issue of version identifiers. I am usually in full agreement with Dave when it comes to the subject of versioning and extensibility. This time, unfortunately, I have to disagree with some of his conclusions.

He writes:

Too often, people use version identifiers to indicate the amount of work that has gone into a version, or as marketing tool. Version identifiers are rarely used to rigorously identify compatible versions.

(emphasis mine). Here, I am in complete agreement. I have emphasized the last sentence because that is, I believe, the reality of the situation. Version identifiers are mostly used as a marketing device. Whether to suggest the amount of effort that went into producing the new version, or for rebranding.

He goes on to state:

Here's a rule that could help: Version identifiers should be rigorously used to identify compatible or incompatible changes.

Here's where I have a fundamental disagreement. You can't wish away the marketing considerations/forces that factor into the selection of a version identifier. They are inevitable. Do you think for a moment that the technology team would have won the argument that J2SE 1.5 needed to be called J2SE 1.5 because it was forwards- or backwards-compatible with J2SE 1.4 when the marketing team insisted that it needed to be called J2SE 5.0? ROTFL! Yeah, riiiight. That might have happened. NOT!

I am all for developing a coherent versioning strategy for a vocabulary that preserves the original namespace, but I am highly skeptical when it comes to exclusive use of version numbering schemes to deal with forwards- and backwards- compatibility.

There are occasionally cases where significant thought has gone into developing an effective versioning strategy. XSLT is such an example.

[Note: a versioning strategy needs to be designed and integrated into the initial release of a system. It is not something that should ever be left for some subsequent release. Adding a version identifier without a clear plan as to how it will be used isn't a versioning strategy.]

Note that the rule that XSLT1.0 used to determine if forwards-compatibility were in effect was to check that the [xsl:]version attribute have a value that was, simply, not '1.0'.

An element enables forwards-compatible mode for itself, its attributes, its descendants and their attributes if either it is an xsl:stylesheet element whose version attribute is not equal to 1.0, or it is a literal result element that has an xsl:version attribute whose value is not equal to 1.0, or it is a literal result element that does not have an xsl:version attribute and that is the document element of a stylesheet using the simplified syntax (see [2.3 Literal Result Element as Stylesheet]). A literal result element that has an xsl:version attribute whose value is equal to 1.0 disables forwards-compatible mode for itself, its attributes, its descendants and their attributes.

The version identifier could just as easily have been an integer. In reality, it serves mostly as an indicator that forwards-compatible mode is enabled. A boolean would have served with equal utility.

However, I personally think that it was a mistake to preserve the XLST1.0 namespace for XSLT2.0 and to use the version identifier to denote backwards-incompatible language features.

Here's why: XSLT2.0 changed the semantics of some of the XSLT1.0 elements and attributes.

Take a look at Appendix J of the XSLT2.0 spec.

Sure, it may be possible to write 2.0 stylesheets that are backwards-compatible. But, as you can see from the long list of incompatibilities, it would be a non-trivial exercise. Most likely, without really effective tools, nearly an impossible task for your average developer to get right even some of the time.

Heck, most developers thought XSLT1.0 was too complicated, and that's without having to deal with the semantic incompatibilities introduced in XSLT2.0.

Imagine the dismay of the poor developer who develops a 2.0 stylesheet (using none of the new features because s/he hasn't had time to learn them) using an XSLT2.0 processor to test it when s/he finds that the results of processing the same stylesheet in a XSLT1.0 processor are different! Oops.

IMO, XSLT2.0 should have defined a new namespace for XSLT2.0 stylesheets, period.