Dave Orchard writes more about versioning in his blog: Elements and Wildcards as siblings
I think that there are some important points he raises in the series of notes he's published recently, including the draft TAG finding on versioning
. Most importantly, are the thoughts on forwards and backwards compatibility of schemas and instances. In designing a schema for forwards compatibility, you want to ensure that application components with an older version of the schema will be capable of validating instances which were created using a newer version of the schema. Further, you want to ensure that a newer version of the schema does not unnecessarily make instances produced using older versions of the schema invalid. This is known as backwards compatibility.
In a distributed system, it is important to accomodate evolution in a manner that doesn't require what is often affectionately known as "the big bang". It is nearly impossible, and certainly highly impractical and very costly in terms of both resources and coordination, to upgrade all components of a distributed system simultaneously to accomodate versioning. I believe that this is what Peter Deutsch cautions against with fallacy number 6
Bottom line, versioning is hard
. Sure, XML is eXtensible. However, as with any tool, what matters is how it is used. In the hands of a skilled practitioner, XML can be very powerful, and can enable the forwards and backwards compatibility that I believe is necessary to successful deployment of a highly distributed system.
Before embarking on a project to design a schema for your application, I would highly recommend that you understand the issues that Dave discusses in his series of articles on versioning and extensibility.