This is the fourth installment of this series about managing backward compatibility in software development. Here I talk about what makes an XML Schema backward incompatible.
I specifically address W3C XML Schemas but general principles applies regardless of the schema language you use.
But first, why bother about XML Schemas compatiblility?
Actually, in enterprise applications, XML is often used either to specify configuration files or interchange formats. With the rise of WebServices and RESTFull applications on the Internet there is also an increase in the use of XML.
Thus, making sure that existing configuration files still work with your new software or, more importantly, that other applications can still communicate with yours can really make a difference.
So, what makes a schema incompatible?
- Changing an element or attribute type to a more restricted type (like adding constraints on a xs:string)
- Changing the order of a sequence in a complex element
- Removing or renaming an element or attribute from a complex type
- Adding a mandatory element or attribute to a complex type without providing a default
Removing complex or simple types will also make it incompatible if:
- Your schema is included or imported by other schemas or
- You do not replace them by compatible anonymous types (compatible meaning equivalent or less strict, e.g. if one defines a simple type JavaClass, which is a xs:string with a constraint, and replaces it with xs:string).
Then, how to preserve backward compatibility?
If some elements of the schema are becoming obsolete, do not remove them. Instead, mark them as deprecated in the schema documentation and, if applicable, remove their mapping to the object model (that way you will not have to maintain the code equivalent of the deprecated elements).
The best strategy I came across so far is using namespacing: If a given schema must be refactored, create a new one, changing its namespace (a good practice is to include the major version of the schema in the namespace).
You then have two options:
- provide an XSL stylesheet that enables the migration of XML documents from the old schema the new one
- provide support code to be able to read both document structures
Of course, the second solution is the most desirable from the operational point of view (and the first one is not always applicable). However, the trade-off is that it is more expensive from the development point of view. Once again, choosing between who is going to do the work (the guy who develops or the guy who installs your application) is a matter of project management.
