The Document Object Model, DOM for short, is an abstract
data structure that represents XML documents as trees of nodes.
Different interfaces
in the org.w3c.dom package
represent elements, attributes, parsed character data,
comments, and processing instructions. All of these interfaces
are sub-interfaces of the common
Node interface that provides basic methods
for navigating and pruning the tree.

The root of the tree is a
Document object that
represents a complete well-formed document.
A parser reads an XML
document from a stream
and builds a Document
object representing that XML document.
The client program calls the methods of
Document
and the other DOM interfaces to navigate the tree and
extract information from the document. Programs can also
manipulate the tree in memory to add, delete, move, or change nodes
in the tree. Programs can even create completely new documents
from scratch in memory which are then written into an XML file.

DOM is defined in the Interface Definition Language (IDL)
so that it’s language neutral. DOM bindings exist for most
object-oriented languages including Java, JavaScript, C++,
Python, and Perl. However, since this is a book about Java,
I will deal exclusively with the Java implementation in this
chapter.

The Evolution of DOM

The first version of DOM wasn’t an official specification,
just the object model that Netscape Navigator 3 and Internet
Explorer 3 implemented in their browsers. (Really, these were
two different object models since they were only marginally
compatible with each other.) This is sometimes called DOM
Level 0.

DOM Level 0 only applied to HTML documents and only in the
context of JavaScript. Nonetheless, both the usefulness of
JavaScript and the growing incompatibility between the two
browser object models made it obvious that something more
standard was needed. Hence, the W3C launched
the W3C DOM Activity and began working on DOM Level 1.
DOM1 was an
attempt to come out with a specification as quickly as possible
that would codify existing practice while achieving some
level of compatibility across browsers. Given the constraints
the working group was laboring under, DOM1 is a surprisingly
good spec. The naming conventions feel a little
wrong to a Java programmer, but DOM1
does provides a solid core of functionality that
covers maybe 75% of what programmers want to do when
processing XML.

DOM Level 2 cleaned up the DOM Level 1 interfaces. The big
change was namespace support in the
Element and Attr
interfaces.
In addition, DOM2 added a number of supplementary interfaces for
events, traversal, ranges, views, and style sheets.
I’ll address these in upcoming
chapters. In 2002, all significant XML parsers that support DOM,
support DOM Level 2. There’s not a lot of reason to worry
about the difference between DOM1 and DOM2. From this point
forward, I’m just going to teach DOM2.

DOM Level 3 is visible not far up the road. Parts of it are
just beginning to be supported by bleeding edge parsers, most
especially Xerces 2.
In the core, DOM3
just adds a few missing pieces needed to allow DOM to fully support all
Infoset properties.
This includes the original encoding and base URI of
the document.
However, DOM3 will also add some crucial functionality
missing from DOM2. In particular,
DOM2 doesn’t provide a
parser-independent means
to create a new Document
object, either by parsing a file or by building one from
scratch in memory. DOM3 will provide standard ways of doing
both. DOM3 is also going to add a lot more support for DTDs and
schemas. But despite all its new features and functionality,
DOM3 will not replace DOM2. Everything that works today in
DOM2 will continue to work the same way in DOM3. DOM3 extends
the DOM into new territory, but it doesn’t change what has gone
before.