Re: [xml] Is the handling of "fake node libxslt" element nodes in xpath.c still needed?

[Daniel Veillard <veillard redhat com>]

On Wed, Jul 05, 2006 at 05:03:02PM +0200, Buchcik, Kasimier wrote:
> Hi,
>
> Can somebody recall and clarify the nature of the
> "fake node libxslt" in xpath.c?

  It was yet another attempt to control the life span of the result value
tree purely from XPath module in libxml2. That didn't work, the only way
as you discovered was to clean them up when exitting the template frame where
they had been created, in libxslt. Basically the XPath module in libxml2
could not possibly handle that problem, it was only possible at the 
libxslt level.

> In XSieve I came across this code:
>
> // Before running XSLT:
> // 1) create temporary output document (~ "variables.c:500")
> // 2) remember old data and set new common data
> //
> container = xsltCreateRVT(ctxt);
> ASSERT_RET_UNSPEC(container, "xsltCreateRVT() failed");
> fakeroot = xmlNewNode(NULL, " fake node libxslt");
> ASSERT_RET_UNSPEC(fakeroot, "xmlNewNode failed");
> xmlDocSetRootElement(container, fakeroot);
>
> Since the comment indicates that this was copied from variables.c,
> one could assume that the original Result Tree Fragments had
> an extra dummy document element in the past.
>
> There's also a TODO in xpath.c:
>
> /*
> * TODO: when compatibility allows remove all "fake node libxslt" strings
> *       the test should just be name[0] = ' '
> */
>
> Does someone know if we can safely remove the test for
> "fake node libxslt" and only leave the name[0] = ' ' test?
> Traversing the affected axes without the need for a string comparison
> would be more efficient.

  That should be fine by now, I just ope people won't upgrade to the new 
libxml2 with an old libxslt (more than one year).

Daniel

-- 
Daniel Veillard      | Red Hat http://redhat.com/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/