While the DOM WG seems to have dropped the concept of a "node key" which could be used to build lookup tables based on node identity (last I knew, they were talking about reintroducing something like userData instead, though that's just the API level and the implementation might use keys), Xalan would actually be Significantly Interested in having such a value available.
For various reasons, Xalan's internal model (DTM) is not quite a DOM, and to read a DOM as input we have to wrap the DTM API around it. That in turn causes us to replicate a significant amount of the DOM's tree structure, since we currently have no efficient way of going from a DOM node to its corresponding DTM "node handle". So if anyone has a particularly clever way to associate a unique integer with each node in a DOM, we're interested in suggestions... even if it winds up being a trick that only works for Xerces. Here's what I've thought of so far: UserData as now prototyped, pointing to an Integer object is one solution, but (a) that requires allocating an object for each value assigned and (b) it risks conflicting with other users of userData. Attaching a magic attribute to elements would sorta work, but (a) it requires modifying the source DOM, which we don't want to do, and (b) it only works for elements; computing other nodes' handle values from the nearest element is possible but inefficient. Besides (c) it requires allocating a whole Attr node, which is even bigger than the Integer object, and (d) making these magic attrs not appear in the DTM model would be a pain. Someone suggested hanging magic event handlers off the nodes to carry this info. But if you put the data field in the event handler object you wind up with the same proliferation of objects as in the previous cases, and if you don't you haven't solved the original problem of how to map a node to an integer. The Xerces-J Version 1 DOM's own implementation of userData is currently assuming that node identity equals object identity -- that there's a 1:1 relationship between node objects and DOM nodes, so that they can reliably be looked up in a hashtable. That'd be perfect for our purposes... but this is an implementation detail which may be subject to change in future versions of Xerces, and I'm reluctant to rely on it for that reason. (That would be a Xerces-only solution, but as I said that's OK as a special-case optimization; we already leverage some other Xerces features when they're available.) I presume Xerces wouldn't want to add an integer field to every node for Xalan's convenience, since Xerces has its own storage-size concerns. But if Xerces2 happened to be generating such a value anyway... The problem, again, is long-term reliance on an implementation detail. (That too would be a Xerces-only solution.) If anyone's got a solution I've missed, please post. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
