>Why does Xalan have yet another DOM implementation (stree) for it internal
use?
Actually, STree was recently replaced by DTM, which isn't even a DOM per se
(though its API is modelled on that of the DOM). There's a fairly
lightweight proxying mechanism for presenting DOMs as DTMs, and a
not-too-heavy mechanism for presenting DTMs as (read-only) DOMs, so
hand-generating a DOM and then passing it in shouldn't be bad... though
hand-generating a SAX stream and letting us build a native DTM from that
may be almost as easy and yield better performance.
To answer your question more directly: No one implementation of the DOM is
perfect for all purposes.Code size, data size, heap management issues and
performance on one operation versus another all trade off against each
other. The DOM which comes with Xerces is a good general-purpose compromise
between these goals, but by going to a custom model we feel we can achieve
a better impedence match between the document representation and the needs
of the XPath/XSLT processor. Using our own model allows us to sacrifice
performance on operations we know will rarely be used in favor of ones
which are used heavily. It permits us to sacrifice some functions entirely
-- for example, supporting only read acess rather than a fully editable DOM
-- in exchange for other benefits such as low-overhead pipelined
incremental construction. It lets us annotate the model with data that a
standard DOM doesn't carry. It lets us build a model which is prefiltered
to eliminate irrelevant whitespace and otherwise more directly matches the
XPath model. It permits some faster mechanisms for testing a node's
semantic type. And so on.
So yes, cost/benefit analysis was performed and continues to be performed,
and a custom model currently looks like a win, We may yet cut back ot a DOM
someday, if one turns up that gives up the performance chracteristics we
need. But given that Xalan has a very specific set of demands for its data
model, I suspect that a specific solution will continue to have an edge
over the more general one.