Why should I support or use the DOM

Why should I support or use the DOM?

Answer:

The DOM API provides a standardized, versatile view of a document's contents. By supporting the DOM API, a program not only allows its data to be manipulated by other routines, but does so in a way that allows those manipulations to be reused with other DOMs, or to take advantage of solutions already written for those DOMs. This interoperability also allows programmers who invest in learning to use the DOM calls to apply those skills to other DOMs.

The intent is that -- if you stick with the standardized APIs -- any DOM implementation can be plugged together with any DOM-based application. The original example of this was dynamic-HTML scripts; by agreeing on the DOM as their standard representation of the document, scripts can be be written that will work properly on all browsers. But this applies to larger-scale programming as well; for example, a server-side solution might be built out of the following reusable components, which may or may not all share a single DOM implementation:

• A database which presents its contents as a DOM tree. (Note that the underlying data presented via a DOM need not itself be DOM-like. The DOM is a tool for manipulating data, not a data structure itself.)
• An XML parser which generates a DOM tree, used to read a stylesheet.
• An XSLT processor which combines these, producing a new DOM tree. ("Extension routines" in the XSLT stylesheet may also access the source document via the DOM.)
• A routine which writes a DOM's contents out to the network in the desired syntax (XML, HTML, or other).

If a better implementation of one of these modules becomes available (a faster XML parser, for example) or if an additional/different processing stage is required, you should be able to unplug the existing connections and plug in the new component with minimal recoding.

(The goal is "no recoding", and that is already the case for many applications, but at this writing the DOM Level 2 APIs are not yet complete enough to promise this for all applications. In particular, some of the tools needed to construct a DOM "from scratch" are not yet exposed in the published APIs, and the DOM has not yet defined a representation for the DTD/Schema information.)

Similarly, while all DOM implementations should be interoperable, they may vary considerably in code size, memory demand, and performance of individual operations. So the ability to unplug and replace the DOM itself may also be very useful. For example, since some parsers can write into a user-provided DOM, you may be able to parse a document directly into the above-mentioned database.

There is one potential downside to using the DOM: As with any generalized set of interfaces, the DOM calls can be used to solve a very wide range of problems, but may not be the optimal solution for any specific problem. The advantages of interoperability and familiarity to users will more than compensate for this in many applications, but you will find that some tasks may call for other interfaces in addition to, or instead of, the DOM. For example, your application may wish to use custom interfaces internally for performance reasons, yet be able to import/export/expose its data via the DOM for convenient access from outside.