DTM is an XML document model expressed as a table rather than an object tree. It attempts to provide an interface to a parse tree that has very little object creation. (DTM implementations may also support incremental construction of the model, but that's hidden from the DTM API.)
Nodes in the DTM are identified by integer "handles". A handle must be unique within a process, and carries both node identification and document identification. It must be possible to compare two handles (and thus their nodes) for identity with "==".
Namespace URLs, local-names, and expanded-names can all be represented by and tested as integer ID values. An expanded name represents (and may or may not directly contain) a combination of the URL ID, and the local-name ID. Note that the namespace URL id can be 0, which should have the meaning that the namespace is null. For consistancy, zero should not be used for a local-name index.
Text content of a node is represented by an index and length, permitting efficient storage such as a shared FastStringBuffer.
The model of the tree, as well as the general navigation model, is that of XPath 1.0, for the moment. The model will eventually be adapted to match the XPath 2.0 data model, XML Schema, and InfoSet.
DTM does _not_ directly support the W3C's Document Object Model. However, it attempts to come close enough that an implementation of DTM can be created that wraps a DOM and vice versa.
Please Note: The DTM API is still Subject To Change. This wouldn't affect most users, but might require updating some extensions.
The largest change being contemplated is a reconsideration of the Node Handle representation. We are still not entirely sure that an integer packed with two numeric subfields is really the best solution. It has been suggested that we move up to a Long, to permit more nodes per document without having to reduce the number of slots in the DTMManager. There's even been a proposal that we replace these integers with "cursor" objects containing the internal node id and a pointer to the actual DTM object; this might reduce the need to continuously consult the DTMManager to retrieve the latter, and might provide a useful "hook" back into normal Java heap management. But changing this datatype would have huge impact on Xalan's internals -- especially given Java's lack of C-style typedefs -- so we won't cut over unless we're convinced the new solution really would be an improvement!