Markup languages such as HTML or SVG provide different ways to include or link programming scriptings to the document. In order to use scripting capabilities on the Web, it is recommend to read the Web Content Accessibility Guidelines [WCAG] before using scripts in your documents, in particular the guideline 6.

Specifications of existing scripting languages such as ECMAScript [ECMAScript] (an industry-standard scripting language based on JavaScript and JScript) only give the syntax, the grammar and the basic types' functionalities (String, Object, Number, ...). These specifications don't give the user access to the user agent functionalities (menus, scrollbars, user events, ...) or to the document (text contents, markup structure, style sheets, ...). This is where the Document Object Model stands in the context of scripting.

In November 1996, the W3C released the first Working Draft of the Extensible Markup Language (XML) specification. Many applications of XML were done since then: editors, repositories, databases, B2B systems, Web content, network protocols, etc.

The XML specification only provides the syntax and the grammar for XML. Being able to access the XML content in an application requires more than that: it requires an Application Programming Interface (API).

Generic APIs for XML can be mostly classified in two categories: event-based or tree-based. The DOM is a generic tree-based API for XML. For more information about event-based APIs and a comparison with tree-based APIs, read the [SAX] documentation "[What is an Event-Based Interface?]" or the DOM Frequently asked question (FAQ) "[What is the relationship between the DOM and SAX?]".

    // get the HTML body element from the document
    var childs = doc.getElementsByTagName("body");
    // there is one HTML body element for each HTML 4.0 document
    var body   = childs.item(0);
    // change the value of the CSS2 color property
    body.style.color = "black";

For a more advanced example, check the DOM Level 2 demo used in the main DOM page [Document Object Model].

The Core platform relies on an internal tree-like representation of the document, and enables you to traverse the hierarchy accordingly. The standard model of viewing a document is as a hierarchy of elements, with the computer building up an internal model of the document based on a kind of tree structure.

The DOM Range and Traversal modules can be used on the Core platform for tree manipulations.

The DOM XML extends the Core platform for specific XML 1.0 needs such as processing instructions, CDATA, and entities.

The HTML DOM provides a set of convenient easy-to-use ways to manipulate HTML documents. The initial HTML DOM merely describes methods, for example, for accessing an identifier by name, or a particular link. The HTML DOM is sometimes referred to as DOM Level 0 but has been imported into DOM Level 1.

This part includes XML-tree manipulation oriented events with tree mutation or user-oriented (such as mouse, keyboard, or HTML-specific) events.

The DOM CSS provides a set of convenient easy-to-use ways to manipulate CSS style sheets or styled documents.

Loading an XML document into a DOM tree or saving a DOM tree into an XML document is a fundamental need for the DOM user. This module includes lots of options to control the load/save operations.

Ever try to access the Document Type Information (DTD) from your DOM application? What is the datatype of an attribute or an element? This module lets the user access an abstract representation of the schema. The schema could be a DTD, an XML Schema, or whatever your DOM implementation support.

The DOM XPath provides a set of convenient easy-to-use functions to query a DOM tree using an XPath 1.0 expression.

The DOM requirements contains all requirements for the Levels of DOM. It is regularly updated to reflect the requirements of the latest Level.

Functionality equivalent to that exposed in Netscape Navigator 3.0 and Microsoft Internet Explorer 3.0 is referred to as "Level 0". There is no W3C specification for this Level.

The first Level of the DOM specifications, DOM Level 1, was completed in October 1998. Level 1 provides support for XML 1.0 and HTML.

The second Level of the DOM specifications, DOM Level 2, was completed in November 2000. Level 2 extends Level 1 with support for XML 1.0 with namespaces and adds supports for Cascading Style Sheets (CSS), events (user interface events and tree manipulation events), and enhances tree manipulations (tree ranges and traversal mechanisms).

The third Level of the DOM specifications, DOM Level 3, is under development. Level 3 will extend Level 2 by finishing support for XML 1.0 with namespaces (alignment with the XML Infoset and support for XML Base) and will extend the user interface events (keyboard). It will also add abstract schemas support (for DTDs, XML Schema, ...), the ability to load and save a document or an abstract schema, explore further mixed markup vocabularies and the implications on the DOM API ("Embedded DOM"), and will support XPath.

DOM Level 1 and DOM Level 2 did not addressed a fundamental piece in XML applications: how to load an XML Document into a DOM tree and how to save a DOM tree into an XML Document. [DOM Level 3 Load and Save] gives you those abilities and more.

This DOM module was designed to provide simple functionalities to query a DOM tree using [XML Path Language 1.0]. A mapping between the data model of XPath and DOM is provided.

The XPathEvaluator interface will evaluate a given XPath expression in the context of a a Node and namespace resolver. The namespace resolver is used to resolve the namespace prefixes used in the XPath expression. Note that a Node can be used as a namespace resolver using XPathEvaluator.createNSResolver. Result objects could be reused. All XPath 1.0 types are supported: number, boolean, string, and node sets. The evaluation can retrieve a snapshot for node sets (modifications to the tree will not affect the resulting snapshot) or an iterator (modifications to the tree can result in invalidating the iterator). XPath expressions can be pre-compiled into an XPathExpression object. Finally, the API introduced the concept of XPathNamespace node, for results involving XPath namespace nodes.

The DOM Events model was introduced in the DOM Level 2 Events module. It has been reused since then in other context, such as XML Events. DOM Level 3 Events module provides a clear separation between the DOM Events model, and the DOM interfaces used to manipulate the events and their listeners.

This module is oriented for guided manipulation using a schema. The document can then be maintain fully or partially validated at any given time:

    if (node.canRemoveChild(secondChild))
        node.removeChild(secondChild);
    

The validation state of a Node can be tested using NodeEditVal.nodeValidity. Default or enumerated values for a given node can be obtained using NodeEditVal.defaultValue and NodeEditVal.enumeratedValues. The list of possible elements in a document or a given element can also be obtained using DocumentEditVal.getDefinedElements(namespaceURI) or ElementEditVal.allowedChildren.

The previous sections are not exhaustive and readers are encouraged to refer to the DOM Level 3 specifications for a full list of functionalities, or more details information on the ones listed here.

DOM Level 3 brings the necessary bits to make the life of DOM developers easier, by providing missing functionalities in DOM Level 2 or adding more user convenient functions.