W3C completes DOM specification
October 21, 1998
The Seybold Report on Internet Publishing Vol. 3, No. 3
Document Object Model soothes cross-browser headaches
Last month the W3C released a recommendation* for the Document Object Model Level 1, a key component of the XML family of standards. The DOM carries important implications for both programmers and publishers, not the least of which is the promise of patching up some of the incompatibilities among different browsers. (*In W3C-speak, a "recommendation" is a standards specification that has been blessed by the consortium; a recommendation is as close to "approved" as the W3C gets.)
According to the spec's introduction, DOM Level 1 is "...a platform- and language-neutral interface that allows programs and scripts to dynamically access and update the content, structure and style of documents." The DOM standardizes the objects for representing HTML and XML documents; creates a model of how these objects can be combined, and specifies a standard interface for accessing and manipulating them.
In plain English, the DOM is an API for accessing content within a browser, an API that happens to know about document structure.
Walking the tree
In contrast to the other XML-related standards, the DOM applies equally to XML and HTML. That's because its API has more to do with how you write software than how you encode and style content.
With the DOM, the labor required to create custom services and to add interactivity to Web pages should shrink. Implementers can use familiar scripting languages to manipulate document structures. Web sites will be easier to build, and applications easier to create, because the next generation of DOM-compliant browsers will not require as much browser-specific scripting.
According to Lauren Wood, chair of the DOM working group, "scripts will run everywhere, even if not equally well, on all products. And, of course, if script writers choose to use a vendor's proprietary extensions to the DOM, then they won't work in other products."
Like the other pieces of the growing family of structured document "recommendations" from the W3C, the DOM has benefited from the decade of experience in programming complex document management tasks with Standard Generalized Markup Language (SGML). Wood explains, "SGML people think of walking the tree, so they want getNext/getPrevious functions. Netscape Navigator 3.0 and MSIE 3.0 only had a way to walk the tree as a flat array [called a collection], which isn't quite the same. So now the DOM has both ways of navigating documents."
Not just for browsers
While originally conceived as a generalized object model for dynamic HTML, one that browsers could use for HTML or XML, the W3C DOM is also an interface to documents in other types of software, including editors and repositories. So, in addition to heavy participation from the usual suspects (IBM, Sun, Netscape and Microsoft), the DOM was crafted with representation from structured editor vendors SoftQuad and Arbortext, repository vendor Texcel, and potential users and implementers, including iMall and Novell.
In Level 1, the DOM working group concentrated on the area of greatest programming redundancy-the differences among disparate Web browsers. Future editions may extend the DOM to operate on multiple documents, to handle events and CSS styles, and to operate as an interface among software programs. Though the priorities of Level 2 have not yet been set, Jonathan Robie, the DOM working group member from Texcel, noted that "the same interfaces that are used in the major Web browsers can be used in any system that provides a programming interface to documents, including document management tools and Web browsers. Currently, each editor, browser, and document repository has its own programming API, and a user who works with several such tools may need to learn a variety of APIs and languages. Having a single API that works for each of these kinds of applications simplifies customization significantly."
Whose got the DOM?
A host of new and old players have produced or promised DOM utilities, including Inso (DynaBase and DynaWeb), Docuverse (info on its SDK can be found at http://www.docuverse.com/domsdk/index.html), IBM (XML for Java; see http://www.alphaworks.ibm.com/formula/xml), Sun (its XML Library is at http://developer.javasoft.com/developer/earlyAccess/xml/index.html, InDelv (http://www.indelv.com) and Media Design inProgress, which uses the DOM for the "emacs-like" editor in its Web publishing products (http://www.in-progress.com).
Of course, both browser vendors are heavily involved in DOM implementations. Microsoft's Dave Wascha, Product Manager for Platform Marketing, explained that although the issuance of the DOM comes 15 months into the IE5 18-month development cycle, the browser will have full support for the DOM core, full compliance with the XML layer and pretty near full compliance with the HTML layer. Complete compliance is the goal, according to Wascha, but will take some time. Netscape has simply said that it will implement the DOM in "future versions" of the browser.
The DOM is one more piece in the interoperability puzzle that the W3C is constructing while the market still cares about vendor independence and cross-application standards. The fact that this is getting done before the Net bandwidth problems are solved is helpful, because it's a step forward for Web publishers who want to create client-side applications, and who realize that it's the software, not just the content, that makes a great site.
For those with a long-range view, the DOM does not reduce the cost of creating well-structured information, but once you've gone to the trouble of putting in all those tags, the DOM should help reduce the cost of creating that cool software that generates the payback for your investment.