On Thu, Apr 06, 2006 at 02:33:17PM +0200, Kasimier Buchcik wrote: > Hi, > > > -----Ursprüngliche Nachricht----- > > Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > Im Auftrag von Kasimier Buchcik > > Gesendet: Mittwoch, 5. April 2006 12:53 > > An: The Gnome XSLT library mailing-list > > Betreff: Re: [xslt] Changes of internal structures > > [...] > > > I'm currently not sure to what extent we want to precompile > > the node-tree of a stylesheet in the case of literal result > > elements: I'm tending to precompile those as well, and hold > > references to some information like character content of > > the stylesheet's node-tree; but I don't know if such an > > additional amount of compilation and memory usage is acceptable. > > The pros doing this would be the possibility to leave the > > stylesheet's tree unchanged. The syntax tree would be independent > > of the stylesheet's tree. Currently we anchor compiled information > > on the ->psvi field of nodes. Changes like stripping of whitespace, > > or excluding result prefixes would be handled on the basis on > > the ST and not the stylesheet's tree. This leads to the possibility > > of using the stylesheet's tree as an input tree; i.e., allows > > document("") > > to work correctly. > > I now realize that leaving the stylesheet's node-tree untouched > is not possible, since it would break compile-time code which uses > extension functions. > _xsltElemPreComp (xsltInternals.h) has the following field: > xmlNodePtr inst; /* the instruction */ > ... this means that code out there relies on the current form the > the stylesheet's node-tree.
and it's used to report errors too. > I must keep my hands away from changing the _xsltElemPreComp > struct, since it *is* actually part of the API (although it's > declared in xsltInternals.h), right? That I'm not that 100% sure about, user code really should not poke in the compiled data, but yeah so far this was open. > Must the stylesheet's node-tree be kept in memory after compilation > time? I guess dropping that and keeping compatibility would make your task extremely hard. > The struct _xsltTransformContext has the following fields: > xsltDocumentPtr styleList; /* the stylesheet docs list */ > xmlNodePtr inst; /* the instruction in the stylesheet */ > ... are those fields expected to be accessed by the user? I would say no, but they are exported ... > If not, i.e. if the stylesheet's tree is not accessed during > transformation time by the user, then there would be a way - and > only then it would make sense - to compile much more stuff like > literal result elements into smaller specialized structures. What do you expect to gain that way ? a tiny amount of memory, not worth chasing IMHO, stylesheet compilation time and size are nearly neglectible compared to transformations costs, except maybe if you have something like DocBook stylesheet and a tiny input doc to transform, and even in such case I would not guess you would gain much. Daniel -- Daniel Veillard | Red Hat http://redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ _______________________________________________ xslt mailing list, project page http://xmlsoft.org/XSLT/ [email protected] http://mail.gnome.org/mailman/listinfo/xslt
