Re: [xslt] Release of libxslt-1.1.3

[Daniel Veillard <veillard redhat com>]

On Wed, Feb 18, 2004 at 08:26:17AM -0500, Marc-Antoine Parent wrote:
> 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.

  Adding node in the input document is not really sane. You could use
the document() and exslt:node-set() to apply templates to data not
in the main input. That sounds quite saner.
  Adding node in the output document is okay, but you'd better make sure
the nodes are created for said document.

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

  from a library standpoint, the API must be preserved. From a user
standpoint it sounds better than relying on hardcoded C extension 
against libxml2/libxslt API.

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/