xsd - What are the best practices for versioning XML schemas?

Question

I often have to design XML schemas for different XML-bases import routines. It is clear that XML schemas will evolve over time or they could contain bugs to be fixed, so it is important to capture the schema's version and to have some mechanism to bind against a specific version.

Currently I have two scenarios:

1. The bug is found within the schema and all schema instances must comply with the fixed version.

2. The schema upgraded and should be considered as preferable but an old one should be also supported.

Finally I came up with storing version information within the namespace of schema:

targetNamespace="http://schemas.company.com/Geodesy/2010/River.xsd"

When fixing a bug I fix it in the same namespace but if I'm about to upgrade a schema then I need to create a new namespace but with upgrade month added:

targetNamespace="http://schemas.company.com/Geodesy/2010/01/River.xsd"

And if I have more than one upgrade in a month then just append a day too:

targetNamespace="http://schemas.company.com/Geodesy/2010/01/17/River.xsd"

Do you know any better approach?

Answer 1

This is such a difficult subject that it's not even funny, and one that I have spent years providing consultancy support for.

There are many best practices out there, but a most of them do not work in all situations. For example, many advocate the use of "xsd:any" to allow extensions, and that is just a recipe for disaster if developers are in charge of maintaining the schema, turning it into a dump.

Here are some tips for you if you're getting started:

• Do not put a minor version number, micro version number, date, or anything else of the sort, into your namespace. Every time you change the namespace, you will break all processing applications.
• Do put a "version" attribute in the XML instance document. That will enable a processing application or a version adapter service to figure out what it is processing.
• Do specify a policy of what constitutes a backwards compatible change, for example: adding optional elements will not break senders, and will not break receivers either if they use a policy of ignoring elements they do not know (JAXB and XMLBeans can be configured this way)

Dood luck!