Sponsored Link •
Elliotte Rusty Harold talks with Bill Venners about the API design principles that guided the design of the XOM (XML Object Model) API.
Elliotte Rusty Harold is a prolific author of numerous books about Java and XML, and creator of the popular Java website Cafe au Lait and XML website Cafe con Leche. He contributed to the development of JDOM, a popular XML processing API for Java. His most recent book, Processing XML with Java, shows how to parse, manipulate, and generate XML from Java applications using several XML APIs, including SAX, DOM, and JDOM.
At a meeting of the New York XML SIG in September, 2002, Harold unveiled an XML processing API of his own design: the XOM (XML Object Model) API. On Cafe au Lait and Cafe con Leche, Harold described XOM like this:
Like DOM, JDOM, dom4j, and ElectricXML, XOM is a read/write API that represents XML documents as trees of nodes. Where XOM diverges from these models is that it strives for absolute correctness and maximum simplicity. XOM is based on more than two years' experience with JDOM development, as well as the last year's effort writing Processing XML with Java. While documenting the various APIs I found lots of things to like and not like about all the APIs, and XOM is my effort to synthesize the best features of the existing APIs while eliminating the worst.
In this interview, which is being published in multiple installments, Elliotte Rusty Harold discusses the strengths and weaknesses of the various XML processing APIs for Java, the design problems with existing APIs, and the design philosophy behind XOM.
Bill Venners: What motivated you to create XOM? What were your personal and business motivations?
Elliotte Rusty Harold: I have no business model for XOM. I don't expect to make any money out of this, certainly not directly, probably not indirectly. More than anything else, at this time I had just finished writing a thousand-plus page book called Processing XML with Java, in which I exhaustively went through SAX, DOM, JDOM, TrAX, Jaxen, and a little bit into some other APIs. Along the way as I was doing this, I just noticed lots and lots of things. I'd say, "This could be better. That doesn't make any sense. That's really silly." And I thought, maybe the time was right for something better.
Most immediately, the specific motivation was that Walter Perry of the New York XML Users Group wrote to me and said, "Hey, do you want to come present to us this September?" I said, "Sure." And I sent him about three possible topics. One topic was, "What's Wrong with XML APIs and How to Fix Them." Walter said, "That sounds like the most interesting one. Why don't we do that?" So I said, "OK, now I've got to actually figure out how to fix them." So I spent a couple of months, part time, developing XOM in preparation for that presentation.
Bill Venners: Did you start from scratch, or did you refactor the JDOM codebase?
Elliotte Rusty Harold: I originally planned to fork JDOM. When I actually
looked at it, however, it rapidly became apparent that it would be easier to start from a
blank page. Currently, there's only one non-public class in XOM that is taken
from JDOM, the
Verifier class. Not coincidentally, that is the
class in JDOM with which I've had the most personal involvement. I wrote the
original version of
Verifier, and various other people have contributed to
it since then. Other than that, there is no JDOM code in XOM.