DOM Modules

DOM2 is divided into fourteen modules in eight different packages. DOM1 roughly corresponds to the Core and XML modules. The other twelve are new in DOM2.

Core: org.w3c.dom

The basic interfaces that can be used to represent any SGMLish, hierarchical tree-structured document including DOMException, DOMImplementation, DocumentFragment, Document, Node, NodeList, NamedNodeMap, CharacterData, Attr, Element, Text, and Comment.

XML: org.w3c.dom

The additional sub-interfaces of Node just for XML documents including CDATASection, DocumentType, Notation, Entity, EntityReference, and ProcessingInstruction. An HTML DOM might not implement these.

HTML: org.w3c.dom.html

Interfaces designed specifically to represent the parts of an HTML document such as HTMLHtmlElement, HTMLHeadElement, and HTMLParagraphElement. These are all sub-interfaces of the core interfaces like Node and Element. These aren’t normally relevant to processing XML documents. However, if you have a DOM aware HTML parser, you can apply the techniques described in this book to HTML as well as XML.

Views: org.w3c.dom.views

The AbstractView and DocumentView interfaces used to associate different views with one document. For instance, applying two style sheets to one XML document could produce two views. This is not supported by most XML parsers.

StyleSheets: org.w3c.dom.stylesheets

Basic interfaces for representing style sheets including StyleSheet, StyleSheetList, MediaList, LinkStyle, and DocumentStyle.

CSS: org.w3c.dom.css

Interfaces that specifically represent CSS style sheets including CSSStyleSheet, CSSRuleList, CSSRule, CSSStyleRule, CSSMediaRule, CSSFontFaceRule, CSSPageRule, CSSImportRule, CSSCharsetRule, CSSUnknownRule, CSSStyleDeclaration, CSSValue, CSSPrimitiveValue, CSSValueList, RGBColor, Rect, Counter, ViewCSS, DocumentCSS, DOMImplementationCSS, and ElementCSSInlineStyle.

CSS2: org.w3c.dom.css

The CSS2Properties class that provides shortcut methods for setting all the different CSS2 style properties.

Events: org.w3c.dom.events

The interfaces in these classes establish a generic system that allows event listeners to be attached to nodes. Events nodes can respond to user interface events like mouse clicks, structure modification events like document edits, and anything else the implementation wants to support. The next four modules define specific kinds of events. However, applications can define their own as well. In practice, events are more relevant to JavaScript and other browser-based script systems than most XML programs; but they can be useful when an XML document is displayed in a browser or otherwise shown to a user.

UIEvents: org.w3c.dom.events

The UIEvent interface signals when a node represented on the screen in some form of GUI has received the focus, lost the focus, or been activated.

MouseEvents: org.w3c.dom.events

The MouseEvent interface signals when, where, and with which keys pressed the user has clicked the mouse, pressed the mouse button, released the mouse button, moved the mouse, or moved the cursor into or out of an element’s graphical representation.

MutationEvents: org.w3c.dom.events

The MutationEvent interface signals that Cerebro has detected a new mutant of exceptional power. Sorry about that one, I couldn’t help myself. Really it signals that a node has been added, removed, or modified in the document.

HTMLEvents: org.w3c.dom.events

The HTML events module doesn’t define any new interfaces. Instead it uses the base DOMEvent interface to report a dozen events specific to web browsers including load, unload, abort, error, select, change, submit, reset, focus, blur, resize, and scroll.

Traversal: org.w3c.dom.traversal

This package provides simple utility classes for performing common operations on a tree such as walking the entire tree or filtering out nodes that meet certain conditions. It will be discussed in depth in Chapter 12.

Range: org.w3c.dom.ranges

This optional module extends DOM to cover sections of documents that don’t neatly match element boundaries. For instance, it would be useful for indicating the section of text that the user has selected with the mouse. It could also be used for XPointer ranges.

Aside from the core and XML modules, not all DOM implementations support all of these modules, or all parts of those modules they do support. Most Java implementations do support the traversal module. The events module is not uncommon. The range module is occasionally supported. As far as I know, only Xerces supports the HTML module. So far I haven’t found any parsers that support the Views, Style Sheets or CSS modules.

The hasFeature() method in the DOMImplementation interface can tell you if that implementation supports a particular feature. Just pass in the name and version of the feature you’re looking for. For DOM Level 2 the version is "2.0".

public boolean hasFeature(String name, String version);

Besides the standard modules, implementations and application-specific DOMs may define additional feature name strings. These non-standard features use a reversed domain name, much like a Java package name, to clearly indicate who is responsible for the feature. For instance, SVG 1.0 uses the feature name "org.w3c.dom.svg" and the version number "1.0" to indicate support for some part of the SVG DOM. It uses the feature strings "org.w3c.dom.svg.static", "org.w3c.dom.svg.animation", or "org.w3c.dom.svg.dynamic" to indicate support for specific parts of the SVG DOM.

Different DOM implementations use different concrete classes to implement the standard interfaces. For example, in Xerces, the org.apache.xerces.dom.DOMImplementationImpl singleton class implements the DOMImplementation interface. In the Oracle XML Parser for Java, XMLDOMImplementation implements the DOMImplementation interface. This class has a simple no-args constructor. Example 9.1 uses this class and constructor to check for the standard features in Oracle.

Example 9.1. Which modules does Oracle support?

import oracle.xml.parser.v2.XMLDOMImplementation;
import org.w3c.dom.DOMImplementation;


public class OracleModuleChecker {

  public static void main(String[] args) {
     
    // parser dependent
    DOMImplementation implementation = new XMLDOMImplementation();
    String[] features = {"Core", "XML", "HTML", "Views", 
     "StyleSheets", "CSS", "CSS2", "Events", "UIEvents", 
     "MouseEvents", "MutationEvents", "HTMLEvents", "Traversal", 
     "Range"};
    
    for (int i = 0; i < features.length; i++) {
      if (implementation.hasFeature(features[i], "2.0")) {
        System.out.println("Oracle supports " + features[i]);
      } 
      else {
        System.out.println("Oracle does not support " 
         + features[i]);
      } 
    }
  
  }

}

Here’s the output from version 9.0.1.1.0A Production of the Oracle XML Parser for Java. You see that Oracle only supports the XML, events, traversal, and range modules. The reported lack of support for core is almost certainly just an oversight. The "Core" feature string was only added in the final draft of DOM 2, and was not present in earlier drafts. The Core module is a prerequisite for all the other modules. It’s hard to believe Oracle really doesn’t support it.

D:\books\XMLJAVA\examples\09>java OracleModuleChecker
Oracle does not support Core
Oracle supports XML
Oracle does not support HTML
Oracle does not support Views
Oracle does not support StyleSheets
Oracle does not support CSS
Oracle does not support CSS2
Oracle supports Events
Oracle does not support UIEvents
Oracle does not support MouseEvents
Oracle does not support MutationEvents
Oracle does not support HTMLEvents
Oracle supports Traversal
Oracle supports Range

Copyright 2001, 2002 Elliotte Rusty Haroldelharo@metalab.unc.eduLast Modified December 20, 2001
Up To Cafe con Leche