A message from Joseph Kesselman (in response to a question of mine)
that may be informative for the Xalan community:
It appears that Xalan is searching down another child tree,
or simply copying the full DOM to a DTM prior to running
the selection; I'm guessing it's the latter. Is this correct?
As I said, DOM2DTM copies (or more accurately, builds a wrapper around)
the DOM incrementally as nodes are demanded by Xalan. But that wrapping
process occurs in document order, so if you ask for a node's next sibling
all of the node's children will be wrapped before that sibling is reached.
We sorta know what needs to be done to improve this; the problem is finding
time to pursue it and finding a sufficiently clever answer to be worth
investing in. As always, if anyone else in the Xalan community wants to
take a crack at it, feel free.
The basic challenge is finding a way to map from a DOM node reference to a
DTM nodeHandle number, so we don't have to replicate all the
previous/next/parent/child relationships; if we can do that, we can avoid
most of the DOM2DTM tables and bind nodes individually on demand rather
than having to follow document order to keep track of what we've done.
Possible approaches include:
a hashtable (but not all DOM implementations are hashable ... I think
Xerces-J nodes currently are, but I don't think they make any promises that
this will be true in the future)
attaching magic attributes to each element (but that requires modifying the
source document, and leaves non-element nodes to be dealt with via some
other mechanism)
attaching magic event listeners (not very efficient, and again requires
attaching data to the source document though at least we wouldn't be
altering its content -- and not all DOMs support the events module)
userData or whatever its DOM Level 3 equivalent winds up being (still in
design, and not all DOMs will support Level 3)
... and maybe others.
When experimenting with this, remember that the DOM doesn't guarantee
object identity for two references to the same node, and that the
isSameNode test which closes that gap is another Level 3 operation. Again,
some DOMs _do_ have a one-object-per-node design... but as our own DOM view
of the DTM demonstrates, some don't.
We may wind up providing several different solutions to support different
DOMs, including the current one as a fallback, and selecting among them in
some semi-intelligent manner.
"Hey, if it was easy they wouldn't pay us."
"But this is Apache. They aren't paying us."
"Oh, yeah, that's right..."
--
Tobias McNulty
Data Description, Inc.
840 Hanshaw Road, Suite 9
Ithaca, NY 14850
Phone: (607) 257-1000
E-mail: [EMAIL PROTECTED]
Web: www.datadesk.com
