What is the Document Object Model?

The Document Object Model (DOM) is an Application Programming Interface (API) for HTML and XML documents. It defines a logical view of documents and the way a document is accessed and manipulated. With the Document Object Model, programmers can create and build documents, walk their structure, and add, modify, or delete elements and content. Anything found in an HTML or XML document can be accessed, changed, deleted, or added using the Document Object Model.

As a W3C standard, one important objective for the Document Object Model is to provide one standard programming interface that can be used in a wide variety of environments and applications. The Document Object Model can be used with any programming language. To maintain programming-language independence, the interfaces are defined in OMG IDL. In addition, the specification includes language bindings for Java and ECMAScript (an industry-standard scripting language based on JavaScript and JScript).

What the Document Object Model is

The Document Object Model is a programming API for documents. The object model itself closely resembles the structure view of the documents it models. For instance, consider this table, taken from an HTML document:

<TABLE>

   <ROWS>

      <TR>

         <TD>Shady Grove</TD>

         <TD>Aeolian</TD>

      </TR>

      <TR>

          <TD>Over the River, Charlie</TD>

          <TD>Dorian</TD>

      </TR>

   </ROWS>

</TABLE>

The Document Object Model represents this table like this:

{short description of image}

In the Document Object Model, documents have a logical structure which is very much like a tree; to be more precise, it is like a "forest" or "grove" which can contain more than one tree. However, the Document Object Model does not specify that documents be implemented as a tree or a grove, nor does it specify how the relationships among objects be implemented in any way. In other words, the object model specifies the logical model for the programming interface, and this logical model may be implemented in any way that a particular implementation finds convenient. In this specification, we use the term structure model to describe the tree-like representation of a document; we specifically avoid terms like "tree" or "grove" in order to avoid implying a particular implementation.

The name "Document Object Model" was chosen because it is an "object model" is used in the traditional object oriented design sense: documents are modeled using objects, and the model encompasses not only the structure of a document, but also the behavior of a document and the objects of which it is composed. In other words, the nodes in the above diagram do not represent a data structure, they represent objects, which have functions and identity. As an object model, the Document Object Model identifies:

the classes and objects used to represent and manipulate a document
the semantics of these classes and objects - including both behavior and attributes
the relationships and collaborations among these classes and objects

The structure of SGML documents has traditionally been represented by an abstract data model, not by an object model. In an abstract data model, the model is centered around the data. In object oriented programming languages, the data itself is encapsulated in objects which hide the data, protecting it from direct external manipulation. The functions associated with these objects determine how the objects may be manipulated, and they are part of the object model.

The Document Object Model currently consists of three parts:

DOM Core represents the common functionality used for all documents.
DOM XML defines additional functionality needed for XML documents.
DOM HTML defines additional functionality needed for HTML documents.

All DOM implementations must implement the DOM Core. In addition, implementations may implement DOM XML or DOM HTML or both.

What the Document Object Model is not

This section is designed to give a more precise understanding of the Document Object Model by distinguishing it from other systems that may seem to be like it.

Although the Document Object Model was strongly influenced by Dynamic HTML, in Level One, it does not implement all of Dynamic HTML. In particular, events have not yet been defined. Level One is designed to lay a firm foundation for this kind of functionality by providing a robust, flexible model of the document itself.
DHTML consists of three components: HTML, CSS and an object model. The DOM represents the Object Model part of DHTML. It acts on HTML documents and can apply CSS styles, but does not define new HTML elements or CSS style rules.
The Document Object Model is not a binary standard. Document Object Model programs written in the same language will be source code compatible across platforms, but the Document Object Model does not define any form of binary inter-operability.
The Document Object Model is not a way of persisting objects to XML or HTML. Instead of specifying how objects may be represented in XML, the Document Object Model specifies how XML and HTML documents are represented as objects, so that they may be used in object oriented programs.
The Document Object Model is not a set of data structures, it is an object model that specifies interfaces. Although this document contains diagrams showing parent/child relationships, these are logical relationships defined by the programming interfaces, not representations of any particular internal data structures.
The Document Object Model does not define "the true inner semantics" of XML or HTML. The semantics of those languages are defined by the languages themselves. The Document Object Model is a programming model designed to respect these semantics. The Document Object Model does not have any ramifications for the way you write XML and HTML documents; any document that can be written in these languages can be represented in the Document Object Model.
The Document Object Model, despite its name, has no direct relationship to the Component Object Model (COM).

Where the Document Object Model came from

Dynamic HTML was an immediate ancestor of the Document Object Model, which originated as a standard to allow Java programs and scripts to be portable among web browsers. However, when the Document Object Model Working Group was formed, it was also joined by vendors in other domains, including HTML, SGML and XML editors and document repositories. Several of these vendors had worked with SGML before XML was developed; as a result, the Document Object Model has been influenced by SGML Groves and the HyTime standard. Some of these vendors had also developed their own object models for documents in order to provide programming APIs for SGML/XML editors or document repositories, and these object models have also influenced the Document Object Model. Finally, the design of the Document Object Model has been strongly influenced by the book Design Patterns: Elements of Reusable Object-Oriented Software, by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides (ISBN: 0-201-63361-2). This book provides a vocabulary for discovering and describing collaborations among objects, and has been very helpful in defining the model we use to represent documents.