XML and HTML: DOM and DOMer

DOM and DOMer

By Michael Floyd

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's called standardization.

When it comes to Dynamic HTML, the problem once again is whose DHTML are we talking about? According to Netscape, DHTML is simply a matter of combining 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 (and now 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." Once again the W3C is attempting to resolve this clash of ideologies, this time with the recently released Document Object Model (DOM) Level 1 Recommendation.

The DOM lays out an object-oriented view of Web pages. Why is this significant? First, 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. In fact, that's how we've been accessing the XML objects in Internet Explorer in previous columns.

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. (See this month's "Script Junkie" for more on this topic.) So, the DOM defines a high-level set of objects that provide an interface between you -- 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).

It so happens that as I write this month's column, the beta version of Internet Explorer 5 was just made available, with all new DOM support included. (This is an update to the Internet Explorer 5 Developer Preview discussed in previous months.) If you want to see where Microsoft is taking XML, then you'll definitely want to take a look at this new version of Internet Explorer (see " Online" for download information). My guess is that you'll see many of these features in the upcoming Office 2000 products.

DOM from Square One

The DOM 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, I'll focus on the core DOM.

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. If you're familiar with the parts of an XML document, then these objects 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.

The New Explorer

The new Internet Explorer 5 Beta, which many refer to as Beta 2, comes with many significant changes over the Internet Explorer 5 Developer Preview. Microsoft had already introduced a completely reworked event model and lots of new features including dynamic properties and CSS behaviors in the Developer Preview. The Developer Preview also let you include XML directly in your HTML documents; the Beta 2 documentation now calls these sections "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. In my original briefings with Microsoft, I was unimpressed with these data islands. Except in specialized applications, I don't see a big 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. But then I realized you can include XML from an external file using a SRC attribute:

<XML ID="xmlDocument"

SRC="../../../../docs/new1013637604/somefile.xml"></XML>

Although documentation was sketchy and I was unable to test all of its features, Internet Explorer 5 Beta appears to fully implement 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's not always clear from the early 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. (Recall from our previous discussion that 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.

In order to access the XML interfaces, you must first create a new document object, which is an ActiveX component. For example, with ECMAScript we 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 column, but I'll cover attributes and methods as we use them in future months.

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 is a significant improvement over the Developer Preview's version. It 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.

Conclusion

While it provides the basis for its XML support, Internet Explorer 5 Beta doesn't 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.

Another draft specification, XSL, is fully supported in this beta release. 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 proposal forwarded by Microsoft that describes a standard method to define the structure and rules of a document much like a DTD currently 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.

As can be seen in this latest release of Internet Explorer, Microsoft has been pushing XML hard. Not only is its browser compliant with the existing standards, the company is proposing many additional XML standards already supported by IE. Yes, even the DOM is DOMer. And if you're wondering what's next in XML, point your gaze into the IE5 looking glass.

Michael is the publisher of BeyondHTML.com and serves as Web Techniques' editor at large. You can reach him at mfloyd@lifestylesSantaCruz.com.