The Artima Developer Community
Interviews | Discuss | Print | Email | First Page | Previous | Next
Sponsored Link

The Good, the Bad, and the DOM
A Conversation with Elliotte Rusty Harold, Part II
by Bill Venners
June 16, 2003

Page 1 of 3  >>


Elliotte Rusty Harold talks with Bill Venners about the problems with the DOM API, and the design lessons he learned from DOM.

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 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.

Dissecting DOM

Bill Venners: What's wrong with DOM?

Elliotte Rusty Harold: There's a phrase, "A camel is a horse designed by committee." That's a slur on a camel. A camel is actually very well adapted to its environment. DOM, on the other hand, is the sort of thing that that phrase was meant to describe.

DOM was designed by committee for many different purposes. It had to work for HTML and XML. It had to work for JavaScript in web browsers and traditional programming languages running on servers. It had to support many different languages: Java, C, C++, JavaScript, AppleScript, Perl, Python, Rexx—and for all I know, INTERCAL. The committee that designed DOM was trying to do all these things. Within the constraints that they were operating under, they failed.

DOM is incredibly complex. It is full of gotchas.

Page 1 of 3  >>

Interviews | Discuss | Print | Email | First Page | Previous | Next

Sponsored Links

Copyright © 1996-2018 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use