Defining the Document Object Model
The term "model" is one of those all-purpose terms that everyone uses. For our purposes, a model is a representation of an object. Models can be complete, incomplete, or somewhere in between. In the case of DOM, the model represents an XML document. An incomplete model only partially replicates the object it models, whereas a complete model mimics everything down to the smallest detail. In the DOM specification, each element of an XML document is represented, making the DOM a complete model. The DOM also defines a set of interfaces that developers, and perhaps others, can implement allowing concrete programmatic representations of XML documents. In essence, the DOM is three things:
Model— The DOM models an XML document. The DOM serves as a complete model representing each and every aspect of an XML object, allowing that object to be completely re-created from the model's data. The DOM Core Level I is a complete model providing for all the required manipulations. The DOM Core Specification says explicitly that "With the Document Object Model, programmers can build documents, navigate their structure, and add, modify, or delete elements and content."
Set of Requirements— The DOM is a set of requirements, defined by the W3C, that each implementation of the DOM must follow. The next section introduces and discusses the DOM implementation requirements.
Set of Object Definitions— The DOM is an object-oriented specification that specifies a set of interfaces, properties, and behaviors for each object. We will examine the interfaces in detail shortly. Examples of properties are getNodeName, getParentNode, and getChildNodes. DOM Object definitions also require that every DOM object follow certain behavioral patterns. An example of these patterns is that each object can have only one parent and can have zero or more children. The exception to this pattern is the root document, which does not have any parents.
At first glance, the DOM appears to be one more thing, an implementation. While individual companies may implement the DOM, the W3C specification provides no implementation. The specification leaves implementation to Sun, IBM, Oracle, or to any user. Anyone could, in fact, implement a DOM. Last time I checked, there were implementations for C++, Python, Perl, Smalltalk, Gecko, and a slew of other languages. For Java alone, companies such as Sun, Microsoft, Netscape, Oracle, IBM, Docuverse and others had all committed to supporting the DOM in one fashion or another and providing Java implementations. Let's now get back to what the W3C actually defined and how we might use it.
DOM Requirements
Because the W3C defines specifications rather than implementations, it needs to define the general requirement of any implementation. The following list, taken directly from the W3C's requirements document for DOM, defines each of these requirements. Let's now look at each to understand what they mean.
The Document Object Model (DOM) is an Applications Programming Interface (API) for HTML and XML— Simple enough, the DOM defines the APIs through which we access XML documents.
The Object Model is language neutral and platform independent— This is perhaps one of the most important aspects of the DOM, DOM specification is not dependent on any specific platform or language. As a result of the independence of the specification, developers are free to provide an implementation in any available language. All the DOM does is specify what interfaces, methods, attributes, and properties the DOM objects provide.
There will be a core DOM that is applicable to HTML, CSS and XML documents— Basically, the DOM Core supports only HTML, CSS, and XML. Don't expect to process some other language with the DOM.
The Object Model can be used to construct and deconstruct the document— Models typically vary in how complete they are. The DOM is defined to be complete. Anything that you can validly create can also be read later.
The Object Model will not preclude use by either agents external to the document content, or scripts embedded within the document— The DOM will not stop you from processing your XML document with some other method (perhaps SAX or your own parser).
Consistent naming conventions must be used through all levels of the Object Model— Properties are properties are properties! A good model is consistent and doesn't change its nomenclature for different objects or at different levels.
A visual UI component will not be required for a conforming implementation of the Object Model— The DOM is a programming API and is not designed around how a document is displayed. No requirements are imposed on how the developer presents DOM modeled documents.
The specific HTML, CSS or XML document object models will be driven by the underlying constructs of those languages— Simply put, DOM objects follow the ebb and flow of the thing they represent rather than force all documents to be represented in a generic format.
It must be possible to read in a document and write out a structurally isomorphic document— If you read in and write out a document, the end result will be the same as the starting result (assuming that you didn't change anything).
The Object Model will not expose the user to problems with security, validity, or privacy— DOM Implementors must not reply on platform, security, or language-specific mechanisms to process XML and HTML documents.
The Object Model will not preclude other mechanisms for manipulating documents— If you have another way for processing your documents, great! The DOM is not the only game in town. You aren't forced to use it if you don't want to!
In addition to the things the DOM is, there are a number of things that are beyond the scope of the DOM. The following list describes some of what the DOM specifically is not or does not provide for.
The DOM does not implement all of "Dynamic HTML," in particular, events— The DOM Core Level I does not specify everything under the sun but rather sets a sound foundation for processing XML. Events and other important but secondary concepts are left to Level II.
The DOM is not a binary specification— While the DOM specifies a number of interfaces, it does not require anything beyond source level compatibility between documents.
The DOM is not a way of persisting objects to XML— The DOM specifies how XML objects are represented via an API but leaves the external representation to XML. The primary focus of DOM is to define how objects can be used in programs, not how they are stored externally.
The DOM is not a set of data structures— While the DOM represents parent/child relationships, these relationships are logical and may be implemented as required.
The DOM does not define "the true inner semantics" of XML— While XML documents are represented as objects within DOM, their underlying semantics are defined by the XML language specification and not by the DOM itself. The DOM is simply a vehicle through which these semantics of an XML document can be manipulated.
The DOM, despite its name, does not compete with COM (The Component Object Model)— COM is a mechanism to specify binary interfaces and objects for runtime interoperability in much the same way the Common Object Request Broker Architecture (CORBA) does. The DOM specifies a number of logical objects and interfaces but does not specify any binary level compatibility.