The Artima Developer Community
Sponsored Link

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

<<  Page 3 of 3

Advertisement

Learning from DOM

Bill Venners: What did you learn from DOM? What things did they do that you thought made sense?

Elliotte Rusty Harold: The single biggest lesson from DOM that comes to mind is that polymorphism is good. It's very useful to have a Node interface or class, which all parts of the XML tree extend in some fashion. Often you just want to walk the tree and work with all the Nodes. You don't care whether a Node is an Element, a Comment, a ProcessingInstruction—you don't need that more specific type. DOM works very well in those cases.

Bill Venners: What kind of processing can you do with a Node irrespective of its more specific type?

Elliotte Rusty Harold: You can merge two documents, for example. You want to select this portion of document A, and copy it into this element of document B. You just want to walk down the tree of document A, and copy each node in the tree into document B.

Bill Venners: One thing you said you learned from DOM is that interfaces are a bad idea. Why?

Elliotte Rusty Harold: I learned that partially from DOM. DOM is designed around interfaces, rather than concrete classes, because it is written in IDL and needs to be compiled to many different programming languages. It relies on the abstract factory design pattern to actually form documents and DOM implementations.

A large part of the trouble of getting started with DOM is learning to work with the interfaces, rather than directly with the classes. If you look at the code many XML novices write with DOM, you'll see it is littered with the implementation classes of the specific DOM implementation, such as Xerces or Crimson.

To some extent mentioning implementation classes is unavoidable, because DOM is incomplete. The Document class serves as an abstract factory for creating Element objects, Comment objects, Text objects, and so forth. The DOM implementation class is an abstract factory, which is used to create Document and DocType objects. However, they left out the part of the abstract factory design pattern, where there's a static method that lets you load the factory itself. You can't load the factory in DOM without using implementation-specific classes. Overall, I just saw that the interfaces were making life more difficult than it needed to be for a lot of programmers.

Bill Venners: You also said that you learned from DOM that successful APIs must be simple.

Elliotte Rusty Harold: Yes, although I suppose DOM is the reverse of that. DOM proves that a complex API is not likely to be successful, at least if it's substantially more complex than what it's trying to model.

Next Week

Come back Monday, June 23 for Part II of a conversation with Bruce Eckel about why he loves Python. I am now staggering the publication of several interviews at once, to give the reader variety. The next installment of this interview with Elliotte Rusty Harold will appear near future. If you'd like to receive a brief weekly email announcing new articles at Artima.com, please subscribe to the Artima Newsletter.

Talk Back!

Have an opinion about XML processing APIs? Discuss this article in the News & Ideas Forum topic, The Good, the Bad, and the DOM.

Resources

Elliotte Rusty Harold is author of Processing XML with Java: A Guide to SAX, DOM, JDOM, JAXP, and TrAX, which is available on Amazon.com at:
http://www.amazon.com/exec/obidos/ASIN/020161622X/

XOM, Elliotte Rusty Harold's XML Object Model API:
http://www.cafeconleche.org/XOM/

Cafe au Lait: Elliotte Rusty Harold's site of Java News and Resources:
http://www.cafeaulait.org/

Cafe con Leche: Elliotte Rusty Harold's site of XML News and Resources:
http://www.cafeconleche.org/

JDOM:
http://www.jdom.org/

DOM4J:
http://www.dom4j.org/

SAX, the Simple API for XML Processing:
http://www.saxproject.org/

DOM, the W3C's Document Object Model API:
http://www.w3.org/DOM/

ElectricXML:
http://www.themindelectric.com/exml/

Sparta:
http://sparta-xml.sourceforge.net/

Common API for XML Pull Parsing:
http://www.xmlpull.org/

NekoPull:
http://www.apache.org/~andyc/neko/doc/pull/

Xerces Native Interface (XNI):
http://xml.apache.org/xerces2-j/xni.html

TrAX (Tranformation API for XML):
http://xml.apache.org/xalan-j/trax.html

RELAX NG:
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=relax-ng

<<  Page 3 of 3


Sponsored Links



Google
  Web Artima.com   
Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us