- From: Vivek Pandey <Vivek.Pandey@Sun.COM>
- Date: Fri, 13 Sep 2002 16:07:22 -0700 (PDT)
- To: Ray Whitmer <rayw@netscape.com>
- Cc: Vivek Pandey <Vivek.Pandey@Sun.COM>, www-dom@w3.org
On Fri, 13 Sep 2002, Ray Whitmer wrote: > 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. I meant removed from the DOM tree. Your comment below answers it. > > 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. > thanks! -vivek. > Ray Whitmer > rayw@netscape.com > -- Vivek Pandey XML & Webservices Sun Microsystems, Inc.
Received on Friday, 13 September 2002 19:07:24 UTC