Learning Java, 4th Edition

DOM

In the last section, we used SAX to parse an XML document and build a Java object model representing it. In that case, we created specific Java types for each of our complex elements. If we were planning to use our model extensively in an application, this technique would give us a great deal of flexibility. But often it is sufficient (and much easier) to use a “generic” model that simply represents the content of the XML in a neutral form. The Document Object Model (DOM) is just that. The DOM API parses an XML document into a generic representation consisting of classes with names such as Element and Attribute that hold their own values. You could use this to inspect the document structure and pull out the parts you want in a way that is perhaps more convenient than the low-level SAX. The tradeoff is that the entire document is parsed and read into memory—but for most applications, that is fine.

As we saw in our zoo example, once you have an object model, using the data is a breeze. So a generic DOM would seem like an appealing solution, especially when working mainly with text. One catch in this case is that DOM didn’t evolve first as a Java API and it doesn’t map well to Java. DOM is very complete and provides access to every facet of the original XML document, but it’s so generic (and language-neutral) that it’s cumbersome to use in Java. Later, we’ll also mention a native Java alternative to DOM called JDOM that is more pleasant to use.

The DOM API

The core DOM classes belong ...