[This local archive copy mirrored from the canonical location: http://www.zdnet.com/pcweek/news/1103/03dom.html; see this official version of the document.]

PC Week Online
News
Labs
Radio
Special Reports
Spencer
Columnists
Downloads

Search
FAQs
Subscribe
PCW Marketing

CompuServe Computing Pro - Where computing professionals network


Turning documents into trees
--------------------------------------------------------- DOM defines object-oriented API for accessing, modifying all of a Web page or XML document

By Eamonn Sullivan, PC Week Labs
11.03.97


Related stories:

RDF aims to tame the Web

Intersights: Fumbling data in the Web's end zone


The Document Object Model standard proposed by the World Wide Web Consortium is like an API for the information on the Web--opening up the basic unit of communication, the Web page, to programmatic manipulation.

DOM, which took its first step toward standardization last month with the release of a draft specification, defines an object-oriented API for accessing and modifying everything on a Web page or XML (Extensible Markup Language) document. The first draft defines the most fundamental API, the so-called "core" of a more extensive system under development at the W3C. Subsequent drafts will provide higher-level APIs for manipulating and querying documents, such as those specifically geared toward HTML documents.

Dynamic HTML is where DOM is needed the most, because DOM provides a standard way for scripts to manipulate information on the page. Once the standard is adopted by Netscape Communications Corp. and Microsoft Corp., authors and developers should have an easier time creating dynamic, script-driven pages that work on both companies' browsers. The method for accessing the content of a document's headings (and optionally changing that content) would be the same across both browsers, for example.

Both Microsoft and Netscape already have a document object model of their own, but the two models are significantly different.

DOM could also provide a standard way for developers to acquire information (possibly from multiple sources) and integrate disparate applications. Using DOM to create and manipulate XML, for example, would allow developers to more easily tie together incompatible databases.

DOM will also give application developers more flexibility, allowing them to separate document management and publishing. A document management system, for example, could expose the information in its documents through DOM, enabling a publishing application to assemble and publish the information to multiple varieties of HTML and XML on the fly. By using DOM as a conduit, the publishing application does not need intimate knowledge of the document management system, and the system can work with any DOM-compatible publishing application.

Turning documents back into trees

In the current draft--which could change substantially by the time it's adopted--the data model used in DOM is a hierarchy of nodes, set up like a tree. The top level of the model is the document itself.

On the next level are the top-level elements of the document, such as the headings, metadata and comments. Element attributes and the text contained in each of those elements are accessible on the next level.

The model is defined using CORBA's (Common Object Request Broker Architecture's) IDL (Interface Definition Language). Using CORBA's IDL is a convenience (it's simple and concise), not a requirement that CORBA be used in all DOM implementations. A preliminary definition of DOM in Java is also provided with the draft spec.

A DOM application starts by obtaining a pointer to the document object (which it would obtain from the browser or document repository). It then uses that pointer to obtain the tree of objects in the document, which is provided to the application through DOM as a series of nodes.

Each of the elements is a node in the DOM tree. A document is a parent node with one or more child nodes for each element. Each element, in turn, is also a node, with child nodes for things like the text contained within the element. Developers manipulate those nodes using "helper" objects in the API, such as NodeList and NodeEnumerator, which include methods such as insertChild(), removeChild(), getParentNode(), getFirstChild() and so forth.

DOM also includes a special node with each document object called a DocumentContext, which contains metadata about the document. Initially, DocumentContext may just include the HTTP headers retrieved with the document and the document's URL, but future enhancements could include significantly more information. An obvious enhancement is to tie DOM with Resource Definition Framework through the DocumentContext object.

Top of page

Send E-mail to PC Week | Copyright notice