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

[Kasimier Buchcik <kbuchcik 4commerce de>]

Hi,

Daniel Veillard wrote:
> 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. 

No pressure... hmm, maby a bit, but not more that 2.3 kg :-)
I just don't want to spend time on testing, if it is of no use. If you 
don't want it inside, we need to consider some workarounds. But if this 
could work, that would be *really* a fine thing.

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

I see. This functionallity is indeed not part of the XSLT-1.0 spec. 
Well, for the complexity of the patch: xsltApplyStylesheetInternal would 
need an additional argument for the initial context node; if it's 
omitted (NULL) then it would take the doc as the initial context node.

 > But that specific implementation keeps me worried
> it's a performance trade-off, and looks dangerous as a general API.

Yes, if we could transform subtrees directly (without the need to clone 
them into a new document beforehand), we would gain a lot of speed. But 
if it keeps you worried, than I bet you have insight on the problems 
that might occur. As far as I learned from you, the problem is:
Some whitespace of the source document is stripped, if required.
Question: if xsltApplyStripSpaces (called by
   xsltApplyStylesheetInternal) will still start the work on the 	
   document element, where would be the difference?
Is there anything else that keeps you worried?

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

Ok.

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

Well, if I would be richer, I would be pleased to pay you for that :-)

Hmm, but I'm still no dime wiser about what to do now... so I'll go and 
smoke a cigarette.


Greetings,

Kasimier Buchcik