- From: Perry A. Caro <caro@adobe.com>
- Date: Wed, 10 Apr 2002 18:50:34 -0400 (EDT)
- 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 UTC