AW: [xslt] Changes of internal structures

["Kasimier Buchcik" <k buchcik 4commerce de>]

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.
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?

Must the stylesheet's node-tree be kept in memory after compilation
time?
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?
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.


Regards,

Kasimier