Even more on version identifiers and XML

Volume 7, Issue 216; 17 Dec 2004; last modified 08 Oct 2010

I'm not opposed to the use of version numbers to identify compatibility implications, I just don't think they always do or always should.

Chris Ferris has joined the fray on version identifiers and XML.

I'm following up just because I don't want to be seen as having taken too strong a stand against version numbers. I don't agree with everything David says, but I don't completely agree with Chris either. (It's Friday, I can be contrary if I want.)

Individual specifications can decide to adopt a convention that forwards and backwards compatibility is manifest in the version number: DocBook has been doing it for more than a decade. The rule for DocBook is simple: backwards incompatible changes can only occur at a major versionIn fact, the rule for DocBook is even more stringent. Not only can backwards-incompatible changes only be made in major versions, they can only be made if they were announced in the previous major version. (The DocBook TC has voted itself a one-time exception to this rule for DocBook V5.0 because we're completely changing validation technologies. No system is without exceptions.) . In other words, all DocBook 4.0 documents are valid DocBook 4.1, 4.2, 4.3, 4.4, and 4.107 (if we ever got that far) documents. DocBook doesn't have any forwards compatibility rules: knowing 4.0 doesn't tell you much at all about 4.1.

My point is simply that it is not always the case that version numbers have direct, unambiguous compatibility implications, nor do I think it necessarily should always be the case. In particular, a specification like XML, which you should ideally never change, isn't likely to be amenable to a simple, rigid numbering scheme.

Specs should say what they're breaking, though, Chris is absolutely right about that. And XML 1.1 does. Right up front. In the introduction. Just like he says.