You are presenting the design of your software's Version 2 to management. This is when the compatibility saga typically begins.
Y: In closing, 'Whizbang' will break V1 compat.
M: Cool! Whizbang sounds fantastic.
Y: [grins]
M: One more thing: will a V1 shop be able to run V2?
Y: Uh, no. We're going to break compat.
M: Are you nuts? Upgrades! Money! Remember?
Y: ... [deflated] ... oh.
Maintaining full compatibility with an old version is a hard problem that any successful project eventually gets stuck with. But if you plan for it, it can become much easier. This article is the first in a series that will show how.
Continue reading "Theory of Compatibility (Part 1)"
When the U.S. Bureau of Engraving lanched the new $20 bill (the new rainbow-colored bill, announced with a bit too much fanfare), they had two main messages for the media. The first was that the new colored bills can be used wherever you used the old bills - they are backward compatibile. The second message was you don't need to go to the bank to turn in your old bills, because they are still sound - they are forward compatible.
"Both the new notes and the older-design notes will continue to be legal currency at full face value. The U.S. has never devalued its currency and will not do so now." - U.S. Bureau of Engraving
Why doesn't the U.S. just pass a law requiring everybody to turn in the old greenback to switch to the hard-to-counterfeit rainbow money? Because the promise of both backward and forward compatibility of currency is one of the bedrock foundations of a modern economy. The committment of permanent compatibility is itself a source of great value.
Continue reading "Theory of Compatibility (Part 2)"
We have a number of ongoing series of articles on this weblog. This week, I'm returning to write the third article in the series on the architecture of XMLBeans.
In the first article, we discussed the principle of type correspondence.
In the second article, we discussed the pinciple of node correspondence.
In this third article, will examine the way binding works for XML schema features of type and element substitution. What does it mean for the Java code you need to write?
Continue reading "The Design of XMLBeans (Part 3)"
In a comment on this weblog, George Datuashvili asked about usage of wildcards in Schema to allow for versioning, observing correctly that it is not easy to do right. My own recommendation? Don't do it. It doesn't work.
Perhaps my assessment is too pessimistic. My friend David Orchard has written a great article on the details how to use wildcards to allow for certain kinds of schema evolution. I highly recommend reading it. But even though he presents what I believe to be the best possible approach for using Schema wildcards for extensibility, there remain significant problems with the approach when applied to versioning.
The "projection" model discussed in my Theory of Compatibility articles provides a viable alternative approach that can work well with W3C XML Schema. But XML Schema wildcards are proposed often enough that here I discuss why XML Schema wildcards don't work very well for compatible versioning.
Continue reading "Wildcards and XML Versioning"
In this space, I've emphasized the advantages of XML as a human-readable data-oriented representation. XML is not the first technology to try to fill this role, and there is a lot to be learned from the classical relational database work started in the 1970s.
One of the dilemmas of XML that was tackled very thoroughly by the relational camp is "how do you normalize your data?" There is a tradeoff between completely normalized application neutrality and human-readable, but application-specific hierarchy. In my opinion, this continues to be an unsolved problem, and it is interesting.
In an ongoing email thread, my colleague Daniel Weinreb (of Symbolics and Object Design fame) has done an excellent job of distilling the problem. That thread is republished here. If you skim the messages, be sure to pause and think about the three "equivalent" XML examples in his second message.
Continue reading "XML and Relational Thinking"