W3C home > Mailing lists > Public > www-dom@w3.org > July to September 2002

Re: XPath namespace nodes

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
Message-id: <Pine.GSO.4.44.0209131605180.29238-100000@arti>

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.



> Ray Whitmer
> rayw@netscape.com

Vivek Pandey
XML & Webservices
Sun Microsystems, Inc.
Received on Friday, 13 September 2002 19:07:24 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:10 UTC