Advertisement

Summary
Elliotte Rusty Harold talks with Bill Venners about the five styles of XML APIs, and the problems with data-binding APIs.

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.

In September, 2002, Harold unveiled at a meeting of the New York XML SIG 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 weekly 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. In this first installment, Harold discusses the five styles of XML APIs and the problems with data-binding XML APIs.

What's Wrong with XML APIs

Bill Venners: What is wrong with XML APIs?

Elliotte Rusty Harold: XML APIs are too complicated, too simple, or both.

Bill Venners: How can they be both too complicated and too simple?

Elliotte Rusty Harold: It depends on which XML API you're talking about. Some APIs, such as DOM, are simply wildly broken and complex in ways that they don't need to be. Other APIs are too simple in that they don't completely and correctly model XML. These APIs try to pretend that XML is simpler than it actually is.

Any reasonable XML API will have some rough spots, because XML has rough spots. Some of those rough spots are design flaws in XML, but an API shouldn't be trying to fix that. A few APIs are both too simple and too complicated at the same time. The designers tried to throw in so many features that the API became excessively complex and hard to understand simply by its sheer size, while at the same time, they didn't actually get all aspects of XML correct.

Far and away the most common problem I've seen has been with namespaces. Namespaces are a real pain. They are difficult to understand. They are poorly designed. And a lot of the APIs that are out there either deliberately or accidentally try to pretend that namespaces are something other than what they actually are.