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 <[EMAIL PROTECTED]> 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/ > [EMAIL PROTECTED] | 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 _______________________________________________ xslt mailing list, project page http://xmlsoft.org/XSLT/ [email protected] http://mail.gnome.org/mailman/listinfo/xslt
