Re: [xslt] Release of libxslt-1.1.3

[Marc-Antoine Parent <maparent acm org>]

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

First, thank you for the correction; I suspected this would be needed; 
but I was not sure whether the doc was expected for other reasons.

>> 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.
>> ...
>> 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.
> ....
>   I don't really have a function for creating a node in the output 
> document.
> maybe I should.

Yesss....
BTW, I did mention that I consider those nodes to be part of the input 
documents, or at least I subject them to templates as if they were. 
Would that be possible with output nodes of the kind you describe?
Actually, I do not need it now, but I was even thinking of faking the 
"parent" link, so that templates that act on these nodes could have 
access to the whole document. Of course, I do not expect this kind of 
trickery to be supported by the API! (though, it is a pretty classical 
DOM change, after all.) However, I do care that templates can be 
applied to these new nodes, and I feel it is a reasonable expectation.

But I think that such a function as you describe would be neeed in all 
cases, and perhaps also one to create a node in the input document (and 
add it properly) if that makes a difference to applying templates.

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

I would hesitate to do this, myself. Would that not cause an API 
lock-in?

Marc-Antoine