Re: AW: [xslt] Changes of internal structures

[Daniel Veillard <veillard redhat com>]

On Thu, Apr 06, 2006 at 02:33:17PM +0200, Kasimier Buchcik wrote:
> Hi,
> 
> > -----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
> 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/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/