Understanding the DOM
Part 2

by Nate Zelnick

Details, details...

Last time we went over the Document Object Model at a high level. Now we’ll dig in a little, and talk about how the proposed recommendation from the W3C will work. As with a lot of the really interesting stuff going on with XML these days, the specs precede the implementations, so there isn’t a good test bed available, but I promise I’ll point to one when one becomes available.

While Part One of this series covered the general ideas of what a DOM is, this time we’ll look specifically at the philosophy, structure and terminology of the W3C proposal. We’ll finish up next time with a look at the methods that let developers create XML documents and manipulate them.

The W3C DOM Working Group’s mission was a tough one. They had to define a very general structure for what a document is, shoehorn as much of the devolved HTML material into that as they could, and provide a general set of constructs that would be usable across all different types of programming environments, languages and styles. Because of that, there is much defined in the proposed recommendation that is up to the platform vendors and parser creators who will implement the basic DOM interfaces.

The first example of this struggle becomes clear in the fact that there are two parallel ways to create and manipulate a document that can be used interchangeably. One is for C++ and Java programmers who are likely to use these languages to build parsers. These interfaces are designed to provide object-oriented programming metaphors like inheritance.

Most likely, however, the majority of Web developers will use the lower-level "everything in a document is a node" approach via scripting. Both sets of interfaces are considered core, however; are part of the basic spec; and are required for interoperability.

The structural elements of the DOM are these generic interfaces that together make up the generalized application programming interface (API) for any XML or HTML document. You can think of these as the building blocks that are used to piece together and run through a document. Everything in the document’s tree is a node that exposes one or more specialized interfaces, depending on what it is and where it sits on the tree (though there are actually very few restrictions).

[ Click here to move to the next part of the article ]

Refresh Daily
Join Editor-in-Chief David Fiedler The Editor With No Time and find truth, justice, and a clue or two.

[ Site Map ]

ActiveX / VBscript

Animated GIF Archive

Browsers

CGI / Perl

Database Connectivity

E-Commerce

HTML-Advanced: DHTML, CSS

HTML / Site Authoring Tools

Intranet/Groupware

Java

JavaScript

Multimedia: Audio / Video / Streaming Technologies

Opinions

Refresh Daily: Editorial Column

Security

Servers & Server Tools

Site Design / Graphics

Site Management / Marketing / Log File Analysis

VRML / 3D

XML

Understanding the DOM Part 2

Details, details...

Understanding the DOM
Part 2