Version Identifiers Best Practice, and XML blew it

|

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. Updated 12/15/04 with Norm's factual corrections

XML 1.1 is an example of this horrible practice. XML 1.1 adds allowed characters - particularly some alphabetic and ideographic characters - to the name production. XML 1.1 is not forwards compatible with XML 1.0 because an XML 1.0 processor can't understand these characters so it will fault.

XML 1.1 content is also not backwards compatible with XML 1.0 content because characters that were allowed in XML 1.0 content - the control characters in the 0x7F-0x9F range - are now not allowed as-is in XML 1.1 content. Thus an XML 1.1 processor cannot read all XML 1.0 content.

There are other changes as well, but the end result is that XML 1.1 is neither backwards- or forwards-compatible with XML 1.0.

To a great extent, XML 1.1 was called 1.1 because it was hoped that this would help foster adoption, rather than xml 1.01 or xml 2.0. I think it's particularly sad that XML has resorted to this kind of marketing effort in it's version identifiers.

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

The update to XML should have been identified as XML 2.0. Henry Thompson asked a really great question at lunch, "following this rule, what changes could have been made to xml that could be called 1.1". And the answer is very few. But he didn't ask the more important follow question "Why are there so few changes that are compatible?"

The reason is that the XML 1.0 has very few extensibility points that allow for compatibility, and name characters are not one of these extensibility points. XML 1.0 decided that any extension, like a control character, results in a fault. It does not have any way of dealing with the extensions that doesn't result in a fault. If it had a substitution model for name extensions, then the XML 1.1 names could be understood by XML 1.0 processors.

There's an axiom that emerges: Forward compatible extensions can only be done if a substitution model for the extensions exist.

If XML 1.0 had provided a substitution model, like the must ignore unknowns, then XML 1.1 truly would be compatible with XML 1.0.

It's ironic that XML itself wasn't designed for compatible extensibility. Maybe the next core technology pieces will follow the guidance that I've regularly written about, like extending and versioning XML with Schema

About this Entry

This page contains a single entry by Dave Orchard published on December 2, 2004 2:50 PM.

Versioning Service Data using WSDL Application Data Feature was the previous entry in this blog.

Noise Cancelling Headphones reviewed, Bose wins is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.

Categories