Compatibility in data exchanges is very different from – and much more complex than – compatibility in traditional software. David Orchard has written extensively about it in a W3C TAG Finding, ‘Extending and Versioning Languages‘. I’ve given some thought to a few concepts in his piece.
First of all, David distinguishes producers and consumers of documents. This complicates the traditional compatibility picture. With say a word processor things are simple – if your V2 word processor can read documents created with your V1 word processor, the V2 processor is backward compatible with the V1 processor. If the V1 processor can read V2 documents, it is forward compatible with V2. Of course no one will buy a V2 word processor, write documents, and then buy a V1 word processor and try to access the V2 documents, so this is uncommon in traditional software applications.
The producer/consumer distinction complicates things. All of sudden forward compatibility matters a lot. There are two possible situations:
- an old producer sends a document to a new consumer; if the consumer needs to read it, the consumer should be backward compatible with the older producer;
- a new producer sends a document to an older consumer; if the consumer needs to read it, the consumer should be forward compatible with the newer producer.
Since there is no universal preferred viewpoint, both back- and forward compatibility are equally important. With preferred viewpoint I mean producers nor consumers are inherently more important than the other. In traditional software, one can assume consumers to be newer than or equal to producer versions: you may try to read old documents with new software, but the reverse is seldom the case without documents being exchanged. However, sometimes there is a preferred viewpoint. In the automobile industry a few huge car makers dominate the market, with many many smaller part suppliers competing for the orders of the few big buyers. The same in consumer goods, where a few large supermarket chains dominate a market with many more food producers. In such cases, the big ones can call the shots and dictate which versions are permissable and which not. The suppliers can comply or go bust. Such an unequality may make backward or forward compatibility more important – depending on whether messages go towards or away from the big shots.
The next question is how to achieve both forms of compatibility. Backward compatibility is relatively easy to achieve: new consumers should support all document features which older producers could make (and which older consumers could read). Forward compatibility is more difficult: the old consumers should be able to process content which they do not yet know about. It can be done by ignoring all unknown content (as in HTML), or having special places in your documents where unknown (read: newer) content is allowed. In XML Schema this can be done with wildcards, special constructs which allow any kind of content where the XML Schema ‘any’ tag occurs (it can be bit more complicated than that in real life, though).This summarizes the main problem area. In a few follow-up posts I’ll explore some of these notions in more detail.