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 Project’s Ælfred, and Yuval Oren’s Piccolo. Most XML parsers implement one or more 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 the parser encounters them. XMLPULL is a similar read-only, streaming API. However, it’s based on the Iterator design pattern rather than the Observer design pattern. That is, in XMLPULL the client has to 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 where 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 programmers than XMLPULL and SAX, mostly because DOM models the XML document while SAX and XMLPULL model the XML parser; and most programmers 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 they can become a standard part of the JDK. However it really isn’t 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 programmer 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 needed by more complex applications. Worse yet, they occasionally increase ease-of-use by catering to common preexisting programmer 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 to standard SAX and DOM for most of my programs.