Re: "Re: [xslt] Apply stylesheet to a subbranch of a document"

[Daniel Veillard <veillard redhat com>]

On Wed, Sep 17, 2003 at 02:29:19PM +0200, Kasimier Buchcik wrote:
> >   That could be done, but I'm afraid it's misleading, for the reason
> > I state: the document is modified, so the subtree would be modified.
> > I'm not sure it's a good idea to then go on processing with a half 
> > modified tree.
> >   I think most entry point called by xsltApplyStylesheetInternal
> > are public, write the modified function and try it this might work.
> 
> If I would test it and everything would be fine, could I persuade you to 
> put it into libxslt, since we don't intend to start a proprietary 
> branch. If you are absolutely unwilling to expand the functionality in 
> this way, there's no reason for me to even try it.

  Hum, do you realize how unfair you are there ? You're putting pressure
on me to accept code within the library, while this code is implemented on
top of the API. Then it's up to me to take on the burden of maintaining
this code which is likely to be messy because it's not a formal part of
the standard, and the side effect could lead people to use it in situations
where they should not. Writing on top of an API is not a fork of said API !
  In general I take patches which don't look dangerous, this functionality
might be useful for others. But that specific implementation keeps me worried
it's a performance trade-off, and looks dangerous as a general API.

> By the way, 2 more questions:
> - do you have any idea how to avoid the _private field during 
> transformation in the future (if this is intended at all for the future)?

  I need it for keys and no alternate solution looks possible so far.

> - if the modified function won't work, is the functionality of 
> transforming subtrees somewhere in the pipe, or do I need to wait for 
> libxslt2?

  Transforming subtree is not described as part of XSLT-1.0 processing,
there is no reason to implement it except your request so far. And I
haven't even expected to go into a libxslt2 major change so far. I doubt
Red Hat would pay me to implement XSLT-2.0 for example.

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/