- From: Ray Whitmer <rayw@netscape.com>
- Date: Fri, 13 Sep 2002 16:03:46 -0700
- To: Vivek Pandey <Vivek.Pandey@Sun.COM>
- CC: www-dom@w3.org
- Message-ID: <3D826ED2.3010105@netscape.com>
Vivek Pandey wrote: >On Fri, 13 Sep 2002, Ray Whitmer wrote: > > > >>For this reason, it is expected that implementations will create >>namespace nodes in response to a query. The DOM XPath API makes it >>clear, I think, that these are identified created during query >>evaluation from the namespace information available in the tree and then >>just forgotten until next time they are requested, when they are >>recreated. If an application were to hold on to the namespace returned >>from one of the previous queries and then later to remove the element >>from a scope which declared the namespace, the namespace node does not >>mutate, not even to null-out it's parent. >> >> > >So it means its applications responsibility to invalidate or remove the >namespace node it was haging on when the element which declared is >removed. right? > >-vivek. > > Remove it from what? Perhaps I do not understand your use case. It was typically never inserted anywhere by the DOM XPath implementation, so what would it be removed from? In a garbage collected system, it just drops to the floor when the application no longer references it, and it is similar with a refcounted system. The same is true of other DOM nodes. If you have a returned element node, the application may hang on to it long after it has been removed from the DOM hierarchy, but that is the application's problem once it hangs onto things after a hierarchy is mutated. Ray Whitmer rayw@netscape.com
Received on Friday, 13 September 2002 19:04:19 UTC