lunedì 25 ottobre 2010

Xml Schema Versioning

It is always cheaper to design the architectural properties of a software at the very early stage of the development process.

Of course which architectural properties are required by a software is a marketing choise: not every software require concurrent access, for example.
Or security. Or easy maintenance.

In some case a code too easy to undestand could actually be a marketing error.
Many big companies live on complex legacy software maintenance.

Unfortunately it's by far more expensive to introduce an architectural property ex post. Most of times such requirement costs more than rewriting from the ground up the application.
Again unfortuately the project managers do not understand this trade off and cut too easily such properties.

A protocol versioning is a good example.

When you deliver a new protocol (eg for comunicating with a third party's software) no one will ask you for a versioning system.
But trust me: the protocol will evolve and you'll have to crack your head against it's versioning and backward compatibility.

I recently had to design a simple xml based protocol for a banking software and I did some research about xml schema versioning.
I found an interesting paper describing the following best practices:
  1. Capture the schema version somewhere in the XML schema
  2. Identify in the instance document, what version/versions of the schema with which
    the instance is compatible.
  3. Make previous versions of an XML schema available.
  4. When an XML schema is only extended, (e.g., new elements, attributes, extensions to
    an enumerated list, etc.) one should strive to not invalidate existing instance
  5. Where the new schema changes the interpretation of some element (e.g., a construct
    that was valid and meaningful for the previous schema does not validate against the
    new schema), one should change the target namespace.

I build my versioning solution on top of the second option.
I set the schema version attribute and I define a matching attribute in the root element:

The restriction in simpleType VersionNumber allow me to list the instance versions that are compatible with the current schema.

This would allow the schema to evolve without breaking the previous versions until the break is a semantic one.

Nessun commento:

Posta un commento