Sponsored Link •
Elliotte Rusty Harold talks with Bill Venners about the benefits of a having single decision maker for an API design and insights gained through writing examples that use the 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 development style did you use when you created XOM? In your talk you said, "This a Cathedral, not a Bazaar."
Elliotte Rusty Harold: So far, XOM has been a one person project. I have written almost all the code. Other users have spotted bugs and suggested features. Occasionally, a line or two of code has been contributed. But basically XOM has been done entirely by me. That may change in the future. There's currently a submission from Bradley Huffman on XPATH, which he wrote. That might go in, but it isn't in the codebase yet.
XOM is my API. I designed it. It's not developed by majority vote. I have certainly occasionally been convinced that I've made mistakes. Sometimes it is really obvious. Sometimes it requires a little more argument. But ultimately, I am the one who decides what goes in and what does not. That process contrasts with the design process for APIs like JDOM, where occasionally things are done by vote. It certainly contrasts with the design process for APIs like DOM, where decisions are made by a very formal procedure of voting and consensus. I think that even if this process makes XOM occasionally a little quirky in places—because like all people I have my little quirks: for example, I don't like method invocation chaining—overall benevolent dictatorships create cleaner APIs. Having one clear vision for an API is better than compromising between many competing visions.