Re: AW: [xslt] Changes of internal structures
- From: Daniel Veillard <veillard redhat com>
- To: The Gnome XSLT library mailing-list <xslt gnome org>
- Subject: Re: AW: [xslt] Changes of internal structures
- Date: Thu, 6 Apr 2006 08:47:01 -0400
On Thu, Apr 06, 2006 at 02:33:17PM +0200, Kasimier Buchcik wrote:
> > -----Ursprüngliche Nachricht-----
> > Von: xslt-bounces gnome org [mailto:xslt-bounces gnome org]
> > 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
I guess dropping that and keeping compatibility would make your task
> 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 Veillard | Red Hat http://redhat.com/
veillard redhat com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
] [Thread Prev