AW: AW: [xslt] Changes of internal structures

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

Hi, 

> Im Auftrag von Daniel Veillard
> Gesendet: Donnerstag, 6. April 2006 14:47
> 
> On Thu, Apr 06, 2006 at 02:33:17PM +0200, Kasimier Buchcik wrote:

[...]

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

Also tor reporting errors during transformation time?

[...]

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

The gain would be that we get something more similar to an AST.
Currently we have a kind of hybrid; not a clean data structure
for its actual purpose. Changes to the AST by the
processor implicate taking care of XML node-tree restrictions.
The problems with the correct implementation of the
"exclude-result-prefixes" mechanism are an example of such
restrictions: just skipping a ns-decl while buidling the
AST is no problem, while removing an ns-decl from the node-tree
is a problem.

An initial proposal:
- Add fields for navigation to the common part the fields of
  a _xsltStylePreComp (and all specialized strucures) in order
  to have a way to traverse the AST without the use of the node-tree.

- Compile literal result elements into just 1 struct
  (e.g. _xsltStylePreCompLRE) with fields referencing the actual
  element in the node-tree. If we can't avoid having the node-tree,
  then we should at least avoid restrictions of the node-tree here.

If there are no fundamental arguments against such an approach, then
I'll try to implement this locally on my side and will see if it
breaks something; then report back.

Regards,

Kasimier