W3C home > Mailing lists > Public > www-dom@w3.org > April to June 2002

DOM 3 XPath: createNSResolver clarifications?

From: Perry A. Caro <caro@adobe.com>
Date: Wed, 10 Apr 2002 18:50:34 -0400 (EDT)
Message-ID: <3CB4C191.9224866F@adobe.com>
To: www-dom@w3.org
Cc: caro@adobe.com
These may be too far into the implementation detail side of things to demand
attention in the spec, in which case perhaps these could be clarified in a
footnote?

What is the lifetime guarantee of the XPathNSResolver returned by
createNSResolver?

I would assume that it is the same as any Node.  For example, in a reference
counting implementation, holding onto an XPathNSResolver returned by
createNSResolver will keep the whole Document tree alive.

[Side Comment: this leads to an interesting challenge in user education,
particularly if non-Node sources of XPathNSResolver are implemented. Trying
to get users to understand that sometimes holding onto an XPathNSResolver
keeps the tree alive, and sometimes it doesn't, will be tough. I'm not
complaining, just making the point for those who plan to implement non-Node
XPathNSResolver instances.]

What are the "liveness" requirements of the XPathNSResolver returned by
createNSResolver, with respect to in-scope namespaces?

I would assume that the lookup must be based on the context node's current
position in the tree, not just the state of the node at createNSResolver
time.  For example, the user creates XPathNSResolver fromFoo from the
Element "foo".  In separate DOM operations, Element "foo" is reparented into
a different part of the tree, with different in-scope namespaces.  I would
assume that the results of using the XPathNSResolver would change to reflect
the new namespace scope.  Please consider making this explicit in the spec.

Apologies if these are deemed to have "obvious" answers.  They weren't
obvious to me.

Perry A. Caro
Adobe Systems Inc.
Received on Tuesday, 16 April 2002 13:56:12 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:13:56 GMT