Re: [xslt] Release of libxslt-1.1.3

[Daniel Veillard <veillard redhat com>]

On Tue, Feb 17, 2004 at 05:04:15PM -0500, Marc-Antoine Parent wrote:
> Good day!

  Hello,

> A change in xsltApplyTemplates (transform.c) did bite me. I was 
> replacing some nodes from the source documents by brand new nodes 
> within a Python extension function. (I suspect my problem was not 
> Python-specific, however.) I was using libxml2.newNode() to create 
> these nodes, which I retured as a list of nodes, probably equivalent to 
> a nodeset. This means that those nodes did not have a document.
> 
> At line 3142 sq of transform.c, you look at the document's name
> 3142                    if ((list != NULL) && (ctxt->document->keys != 
> NULL)) {
> 3143                        if ((list->nodeNr != 0) &&
> 3144                            (xmlStrEqual((xmlChar 
> *)list->nodeTab[0]->doc->name,
> 3145                               (const xmlChar *) " fake node 
> libxslt")) &&
> 
> In my case, list->nodeTab[0]->doc is NULL. I suspect I was misusing the 
> API, but I would have liked learning about it in a way other than a 
> segfault ;-)

  Hum, the test for (list->nodeTab[0]->doc != NULL) was missing.
I'm adding it, that's really the cause of the bug.

> I got out this situation by setting the new nodes' document to the 
> source document, a blatant lie, but it made libxslt happy.

  It's a bit dangerous, though. The best is to use newDocNode, 
with the document being the document of the current insertion
point. I.e. getting tctxt.insertNode() and reusing its document.

> Maybe there is a proper protocol for inserting source nodes which I do 
> not know about; maybe there should be a xsl-oriented variant of  
> xmlNewNode which would insert the "fake node libxslt" pseudo-document; 
> maybe it is a bad idea in the first place...
> But I thought you should know about this possibility.

  I don't really have a function for creating a node in the output document.
maybe I should.
  Another way to build those extentions in a simpler way and possibly safer
to would be to expose some of the libxml2 and libxslt internal APIs as
extension functions in the xsltproc namespace. Since I have XML descriptions
for them it would be relatively trivial to generate the extension interfaces
automatically and have them linked within the libxslt or libexslt library.
That's just a possibility, I didn't work on it, just toying with the idea.

Daniel

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