Lists Home |
Date Index |
Philippe Le Hegaret wrote:
> > It would be nice if the Node interface had a "hook" property -- that is,
> > a read/write property in which the user could store any value they like.
> Check the DOM Level 3 Core draft:
> The intent is to address the "hook" property as well as memory management
> associated with it and multi-threading environment.
> Feedback is welcome.
That does exactly what I need. (My code wouldn't use the UserDataHandler
interface, but it's easy to imagine code that would.) My only objection
is the name "DOMKeyObject", which sounds like a key, not data.
"DOMDataObject" or "DOMUserDataObject" would be better.
> > Another use (inspired by recent discussions on xml-dev) would be storing
> > the current namespace scoping information. I am certain that many other
> > uses/abuses could be found as well.
> As a side comment, the DOM Level 3 XPath gives you this information:
> We didn't find any interest or enough use cases to add this Node into
> the DOM Level 3 Core module. XPath was our only main one.
Too bad. This would be useful for anyone traversing the tree and wanting
to discover what namespace declarations are in force at the time. Two
use cases are:
1) Figuring out if you need to add an xmlns attribute after moving a
node from one location to another. (I would prefer that DOM did this for
you, but in the absence of that, this node would be very useful. The
alternative is to traverse the path back to the root and figure it out
2) Resolving QNames in attribute or element content. I'm not sure how
many languages do this, but at least some do.
Note that it would be most useful if, instead of having a set of
Namespace Nodes, I could simply call Node.getPrefix(uri) and