About a week ago my article Designing Extensible, Versionable XML Formats appeared on XML.com. However due to a “pilot error” on my end I didn't send the final draft to XML.com. By the time I realized my mistake the article was already live and changing it would have been cumbersome since there were a few major changes in the article.

You can read the final version of the article Designing Extensible, Versionable XML Formats on MSDN. The main differences between the MSDN article and the XML.com one are

  1. Added sections on Message Transfer Negotiation vs. Versioning Message Payloads and Version Numbers vs. Namespace Names

  2. Added more content to the section Using XML Schema to Design an Extensible XML Format especially around usage of substitution groups, xsi:type and xs:redefine.

  3. Amended all sample schemas to use blockdefault="#all".

  4. Added an Acknowledgements section

  5. Schema in for section New constructs in a new namespace approach uses a fixed value instead of a default value for mustUnderstand attribute on isbn element.


Saturday, July 31, 2004 4:34:19 PM (GMT Daylight Time, UTC+01:00)
With that article you wrote, can it help me to write a versionable XML schema? Right now I use Binary Serialization, but everytime I changed add/remove property in a class, it's basically a new version.

I was thinking using XML serialization to resolve the versioning issues, but is that the right way to do things?
Tuesday, August 3, 2004 5:05:53 PM (GMT Daylight Time, UTC+01:00)
I read the article once during the weekend. First of all, nice job. I probably need to read this again again but anyway, I have a comment to make.

As I understand, you are proposing to create extension points using xsd:any. This is basically a container that is saying “put whatever you want here". The nice feature of xsd:any is that an extended instance is valid against the original definition.

Then, what’s the problem? I think the problem is regarding XML formats that are used in e-business transactions. In messages used for transactions (i.e. buying/selling product), you don’t want to allow people to add unknown extra information, because your systems can’t understand it, and you don’t know whether it affects the intent of the sender’s message in a way that could lead to a misunderstanding of the contract.

Where can this approach be used? well, things like RSS, which is purely informational and if extra information added by the extensions is not understood by systems it is not critical for the process.

Comments are closed.