Re: [xslt] XSieve: XSLT + Scheme



  Hello Daniel,

  sorry for late answer. It seems my mailbox was disfunctioning for
a while.

On Wed, 7 Sep 2005 17:21:36 -0400
Daniel Veillard <veillard redhat com> wrote:

> On Thu, Sep 08, 2005 at 01:06:18AM +0400, Oleg A. Paraschenko wrote:
> >   I don't remember all the libxslt-related puzzles. But I remember
> > the top two:
> > 
> > * libxml automatically joins text nodes in xmlAddChld. This broke
> > xmlNodePtr<->Scheme value mapping.
> 
>   It is IMHO the XPath data model:
>     http://www.w3.org/TR/xpath#section-Text-Nodes
>     "As much character data as possible is grouped into each text node:
>      a text node never has an immediately following or preceding sibling
>      that is a text node."
>  it is compliance to the XSLT-1.0/XPath-1.0 data model.

  Well, I'm agree.I haven't though about it.

> 
> > * libxslt optimizes "xsl:text", and it isn't described in
> > documentation.
> 
>   well the compilation process is not fully described, it would take ...
>   the
> source code more or less :-)
> 
> > Thanks gdb for assistance in fixing a related bug:
> > 
> > http://uucode.com/blog/2005/08/23/nasty-libxslt-surprise/
> 
>   hum, I'm not sure I follow that description, what did you give to 
> the xslt compilation ?

  I didn't change the xslt compilation. Let me reformulate the problem.
I have a code which adds to the output tree, and a code which implements
an xslt extension element. The first code sometimes adds text nodes, but
it doesn't know about xslt context and all that last*-variables. As
result, the variables are not updated, and next growing might start at an
incorrect position. The bug.

  The second code doesn't know if the first code added a text node or not,
but assumes that added. To avoid the bug, it switches off the optimization
by resetting "lasttext" to NULL.

>   For lasttext lasttsize and lasttuse, when you save as text you
>   basically
> output to one text node over and over. If you don't preallocate/add when
> growing text node you hit a quadratic behaviour killing performances 
> really really fast. So when growing repeatedly a text node, those 3
> variables are used to increment a preallocated buffer and go back to a 
> linear behaviour. You just had to ask I would have answered I think
> in that case there is a very good reason for this processing :-)

  I understand the reason for the optimization, so I didn't need to ask.
The only question is if the optimization really helps in real stylesheets,
but I hadn't time to ask it.

>   At least now it is documented in the archived, indexed public list ...
> 
> >   Anyway, I'm happy with libxml/libxslt. Thank you for great work!
> 
>   Thanks,
> 
> Daniel
> 
> -- 
> Daniel Veillard      | Red Hat Desktop team http://redhat.com/
> veillard redhat com  | libxml GNOME XML XSLT toolkit 
> http://xmlsoft.org/
> http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/


-- 
Oleg Paraschenko  olpa@ http://xmlhack.ru/  XML news in Russian
http://uucode.com/blog/  Generative Programming, XML, TeX, Scheme


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]