XML for Java Developers
G22.3033-002
Dr. Jean-Claude Franchitti
New York University
Computer Science Department
Courant Institute of Mathematical Sciences
Session 5: Understanding the
Document Object Model (DOM)
(Adapted for presentation
from Michael Floyd’s Article at http://www.webtechniques.com/archives/1999/02/beyo/)
Course Title: XML for Java Developers
Course Number: g22.3033-002
Instructor: Jean-Claude Franchitti Session:
5
Lacking more sophisticated
tools, early man used his own body to measure lengths, it is said. In many
cases, the unit of measure was his foot. As the foot measure came into
widespread use, the problem was whose foot were they talking about? Eventually,
the foot of a king was chosen as the foot by which all lengths would be
measured. That is called standardization.
Once again the W3C is
attempting to resolve clashes of ideologies, this time with the Document Object
Model (DOM) Level 1-3 Recommendations. The DOM lays out an object-oriented view
of Web pages. Why is this significant? First, when it comes to client-side XML
processing, both major browsers, which are written in C++, break down the
components of a Web page into a collection of objects that can be manipulated
internally by the browser's software. A bonus is that you, too, can access
these same objects using a programming language like Java or a scripting
language such as ECMAScript.
While these objects live in
the browser, each has its own set of attributes (or properties) and behaviors
(methods). The problem is that each browser represents its internal objects
differently and the calls you make to these objects are also different. So even
though there are standardized languages like Java and ECMAScript, Web
developers still must write different code to support each browser. So, the DOM defines a high-level set of
objects that provide an interface between the developer and the browser's
internal objects. Each DOM-compliant browser must support a core set of XML
objects (DOM Core) and an additional set of HTML objects (DOM HTML). Many of
these features are available in Office 2000 products.
The DOM Level 1 Specification is split into two sections: DOM Core, which defines a set of XML object interfaces; and DOM HTML, which builds on the core DOM interfaces. Due to their complexities, we will focus on the core DOM Level 1 Specification. The following references provide details of the current DOM specifications.
|
Document Object Model Recommendations
(DOM Level 1-3): Internet Explorer 5 (and
6) Microsoft's DOM Reference |
The core DOM defines a
tree-like structure (referred to conceptually as a structure model) of Node objects. That is,
everything in the tree is a Node.
These Nodes
may either be a subclass or a leaf Node.
Figure 1 presents the Node objects that make
up an XML document.
Document
Element
ProcessingInstruction
Comment
DocumentType
DocumentFragment
Element
ProcessingInstruction
Comment
Text
CDATASection
EntityReference
DocumentType
EntityReference
Element
ProcessingInstruction
Comment
Text
CDATASection
EntityReference
Element
Element
Text
Comment
ProcessingInstruction
CDATASection
EntityReference
Attribute
Text
EntityReference
ProcessingInstruction
Comment
Text
CDATASection
Entity
Element
ProcessingInstruction
Comment
Text
CDATASection
EntityReference
Notation
Generic Interfaces
If you're familiar with the
parts of an XML document, then the DOM Node objects listed in the previous
sub-section will look familiar to you. The first is the top-level Document object, which
represents the entire HTML or XML document. As in XML, a Document can contain an
element, a processing instruction (PI), comment, and document type. The other
document object, DocumentFragment,
is a special Node
type designed so that you can temporarily save portions of the document tree.
This could be useful when performing a cut-and-paste, for example.
As you may recall, XML
entity declarations let you associate a name with a content fragment in the
document. The fragment can either be text within the document, part of a
document type declaration (DTD), or a reference to an external file. Entities,
which are represented by the Entity
object in the core DOM, are often used to break up larger documents into
workable chunks. Note that Entity
does not model the entity's declaration; it represents the entity itself.
However, you can use the DocumentType
object to access a list of entities within that document. When you want to,
say, insert an entity within a document, you can access a reference to it using
EntityReference.
Elements, the building
blocks of XML, are supported by the Element
object. An Element
can contain another element, text, a comment, a processing instruction, an
entity reference, and CDATA. Attributes are supported by the Attribute object and can
contain either text or an entity reference. Comments and text, which are both
leaf nodes, are supported by their respective objects. Processing instructions,
which are used to supply applications with data, are supported by the ProcessingInstruction
object. Finally, the Notation
object lets you access notations, which are used to identify external binary
data.
Other Interfaces
The DOM also specifies two
other interfaces: NodeList
to handle ordered lists of Nodes,
and NamedNodeMap
to handle unordered sets of Nodes
based on their name attributes. An interesting feature of the DOM is that NodeLists and NamedNodeMaps are
defined to be "live." This means that whenever you change the
structure of your document, the changes will be automatically reflected in your
NodeLists
and NamedNodeMaps.
If this weren't the case, you'd have to "refresh" these each time a
change was made.
In addition to the class
hierarchy presented above, the core DOM also defines a set of interfaces that
can be accessed directly as a Node.
As the Level 1 spec points out, this creates a "flattened view" of
the object hierarchy: Everything is a node. The reason is that the
object-oriented structure model can be costly to implement, in terms of
performance. So, the DOM provides this alternative interface, which is broken
into two categories: fundamental and extended. To be considered compliant,
browsers must fully implement the fundamental interfaces including those that
claim to support just the DOM HTML. The extended interfaces are not required by
DOM HTML applications since these interfaces are specific to XML documents.
Microsoft introduced a
reworked event model and lots of new features including dynamic properties and
CSS behaviors. IE5 lets you include XML directly in your HTML documents; these
sections are referred to as "data islands."
You create a data island by
wrapping your markup within an <XML>
tag.
<XML
ID="xmlDocument">
...some
XML markup... </XML>
When the browser's parser
sees the <XML>
element, it creates the appropriate document structure, which you can access
through the ID
attribute -- in this case, xmlDocument.
Except in specialized applications, there does not seem to be a need for
embedding hand-coded XML in HTML documents. The majority of XML markup will be
generated automatically by applications, such as those used to pass a database
record to a spreadsheet. However, you can include XML from an external file
using a SRC
attribute:
<XML
ID="xmlDocument"
SRC="somefile.xml"></XML>
Internet Explorer 5 fully
implements the core DOM. Microsoft prefixes the DOM object names described in
Figure 1 with "IDOM." Thus, the root document object is referenced as
IDOMDocument
and the element object is IDOMElement.
Although it is not always
clear from the documentation, Microsoft offers collections of both object
interfaces and Node
interfaces as required by the core DOM. Unless you're a C++ programmer, you'll
want to make sure you're working with and looking at the documentation for the
object interfaces. (The Node
interface is a direct API that avoids the overhead associated with a pure
object-oriented approach.)
The DOM Level 1
Recommendation also permits extensions to the basic objects, and Microsoft has
wasted no time in extending its objects to support XML schemas, namespaces,
data types, and eXtensible Style Sheets (XSL). In the API, Microsoft-specific
extensions start with the "IXMLDOM" prefix. So, the extended root
object for a document is IXMLDOMDocument.
Table 1 lists the Microsoft extended objects.
|
OBJECT |
DESCRIPTION |
|
IXMLDOMDocument |
Extends the DOM Document interface to support
namespaces, schemas, data types, and XSL. |
|
IXMLDOMNode |
Extends the DOM Node interface with methods to
support namespaces, schemas, data type, and XSL. |
|
IXMLDOMNodeList |
Adds iterators and support for indexed
collections. |
|
IXMLDOMNamedNodeMap |
Adds support to NameNodeMap for namespaces. |
|
IDOMParseError |
Returns error information from the parser. |
|
IXMLHttpRequest |
Lets you make an HTTP request. |
|
IXTLRuntime |
Adds support for XSL. |
In order to access the XML
interfaces, you must first create a new document object, which is an ActiveX
component. For example, with ECMAScript, you would use the following statement:
var
xmlDocument = new ActiveXObject("Microsoft.XMLDOM");
This creates an extended DOM
object and assigns it to the xmlDocument
variable. From here you can get the root object of the document using the documentElement method:
var
rootElement = xmlDocument.documentElement;
documentElement returns an
IDOMElement object, which contains the methods you'll need to access and
manipulate element nodes and their attributes within the tree. A complete
discussion is beyond the scope of this handout.
The next extended object in
Table 1, IXMLDOMNode,
also adds to the standard DOM interfaces with support for schemas, namespaces,
and data types. And as with NodeList,
IXMLDOMNodeList
lets you either iterate through a collection, or access the collection as you
would a traditional indexed array.
IXMLDOMNamedNodeMap adds support for namespaces
to the NamedNodeMap
object, and IDOMParseError
returns error information from the parser. This last object provides validation
and indicates offending line numbers, character positions, and so on. Finally, IXMLHttpRequest lets
clients communicate with HTTP servers, and IXTLRuntime adds
specific support for XSL.
XML Support in IE5
Netscape support for DHTML
simply combines JavaScript with HTML in order to make Web pages interactive.
Microsoft's vision, somewhat more ambitious, takes a document-centric approach
that views an HTML/XML document as a container of objects that can be
manipulated. Thus we can, for example, change the value of the COLOR attribute
for the <FONT> tag from "red" to "blue."
While it provides the basis
for its XML support, Internet Explorer 5 does not stop with the DOM. For
example, Microsoft has been a huge proponent of XML namespaces, which allow
software developers to associate unique identifiers with XML names. This solves
the potential problem where the same names
in different documents collide.
The XSL (draft)
specification, is fully supported in IE5. For example, you can view XML
directly in the browser by placing a processing instruction in your XML code or
document and linking your XML markup to a style sheet (either XSL or CSS).
There's also a complete API for managing style sheets.
XML Schema is another W3C
recommendation initially proposed by Microsoft that describes a standard method
to define the structure and rules of a document much like a DTD does.
Considered a subset of XML-Data (yet another Microsoft proposal), XML schemas
let you create these definitions directly in XML. Also related to schemas are
typed values, a feature that lets you define your own data types in XML and
associate values with these types. In addition, Internet Explorer introduces
several built-in data types, including the enumerated types and a set of
tokenized types as defined in XML 1.0 -- roughly 25 so-called "rich data
types" that include Boolean,
char, float, date, time, and so on.