DOM2 is divided into fourteen modules organized in eight
different packages. DOM1
corresponds to the
modules. The other twelve modules are new in DOM2.
The basic interfaces that can be used to represent any
SGML-like, hierarchical, tree-structured document, including
The additional subinterfaces of
just for XML
. An HTML DOM might not implement
to represent the
HTML document, such as
are all subinterfaces of core interfaces like
. These aren't normally relevant to processing XML
documents, but if you have a DOM-aware HTML parser, you can apply
the techniques described in this book to HTML as well as XML.
used to associate different views with one document. For example,
applying two stylesheets to one XML document could produce two
views. This is not supported by most XML parsers.
Some basic interfaces for representing stylesheets, including
Interfaces that specifically represent CSS style sheets
class, which provides shortcut
for setting all of the different CSS2 style properties.
The interfaces in these classes establish a system that allows
event listeners to be attached to nodes. Events nodes can respond
interface events, such as mouse clicks, structure
modification events like document edits, and anything else the
implementation wants to support. The
four modules define
specific kinds of events. However, applications can define their
and other browser-based script systems than they are to most XML
programs; nonetheless, events can be useful when an XML document is
displayed in a browser or
shown to a user.
interface signals when a node represented
on the screen in some form of GUI has received the focus, lost the
focus, or been activated.
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
interface signals that Cerebro has
a new mutant of exceptional power. (Sorry about that one,
I couldn't help
.) Really, it signals that a node has been
added, removed, or modified in the document.
The HTML events module doesn't define any new interfaces.
Instead it uses the base
interface to report a
events specific to web browsers, including load, unload,
abort, error, select, change, submit, reset, focus, blur, resize,
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. Chapter 12
discusses it in depth.
This optional module extends DOM to cover sections of documents
that don't neatly match element boundaries. For example, it would
be useful for indicating the section of text that the user has
selected with the mouse. It also could be used for XPointer
Aside from the core and XML modules, not all DOM implementations
support all of these modules, or all parts of the modules that they
do support. Most Java
do support the traversal
module; the events module is not uncommon; and 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, StyleSheets, or CSS modules.
In addition to the standard modules, implementations and
application-specific DOMs may define additional feature name
strings. These nonstandard features use a
much like a Java package name, to clearly
responsible for the feature. For example, SVG 1.0 uses the feature
and the version number
to indicate support for some part of the SVG DOM. It
uses the feature strings
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
class implements the
interface. In the
Oracle XML Parser for Java,
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.
Following is the output from Version 126.96.36.199.0A Production of
the Oracle XML Parser for Java. Notice that Oracle only supports
the XML, events, traversal, and range modules. The
support for core is almost
just an oversight. The
feature string was only added in the final draft of
DOM2 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.