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.
>

thanks!

-vivek.

> Ray Whitmer
> rayw@netscape.com
>

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

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