Summary

Reading an XML document is a complicated, error-prone operation, which is why it's fortunate that you never have to write the code that does this. Instead you install an XML parser class library and only access the document through the parser's API. Numerous XML parsers for Java are available as free beer, open source, and payware, including the Apache XML Project's Xerces, Sun's Crimson, Enhydra's kXML, the GNU Classpath Extensions Project's lfred, and Yuval Oren's Piccolo. Most XML parsers implement one or more of the standard APIs such as SAX, DOM, and XMLPULL. As long as you only write code to the standard APIs, you can change the underlying parser with relatively little effort.

Which API you pick is largely a matter of personal taste and appropriateness for the problem at hand. SAX is an event-based API that presents the contents of a document from beginning to end in the order that the parser encounters them. XMLPULL is a similar read-only, streaming API, but it's based on the Iterator design pattern rather than the Observer design pattern. That is, in XMLPULL the client must ask the parser for the next chunk of data, whereas in SAX the parser tells the client when it has a new chunk of data. Both SAX and XMLPULL can manipulate documents larger than available memory.

SAX and XMLPULL both work well for documents in which the processing is local; that is, where all the information the program needs at one time tends to be close together in the document. Programs that need random access to widely separated parts of the document are often better served by one of the tree-based APIs, such as DOM or JDOM. These often feel more natural to developers than XMLPULL and SAX, mostly because DOM models the XML document whereas while SAX and XMLPULL model the XML parser. And most developers are more interested in what's in the document than how the parser behaves. The flip side is that SAX and XMLPULL are much easier APIs for parser vendors to implement, so that some parsers implement SAX or XMLPULL but not DOM. JAXP bundles both SAX and DOM together so that they can become a standard part of the JDK. But JAXP isn't really a separate API in itself.

In addition to DOM, there are several alternative tree-based APIs that layer on top of an underlying parser. These include JDOM, ElectricXML, and dom4j. These all correct various perceived flaws in the DOM API and often seem easier to use to a Java developer with little background in XML. However, in my experience these APIs are much more limited than DOM and SAX and leave out some important information from an XML document that more complex applications need. Worse yet, they occasionally increase ease-of-use by catering to common preexisting developer misconceptions about XML syntax and grammar, and thus help propagate the mistaken beliefs. SAX and DOM are both much more in sync with the broad family of XML specifications from XML 1.0 on up. These days I try to stick with standard SAX and DOM for most of my programs.