Re: [xslt] Changes of internal structures

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

Hi, 

> von Frans Englich
> Gesendet: Mittwoch, 5. April 2006 12:27
> 
> On Tuesday 04 April 2006 11:32, Kasimier Buchcik wrote:
> [...]
> 
> > The plan is to have specialized structures for each of the xslt 
> > instructions to hold precompiled data. 
> 
> As a general idea, I wholeheartedly recommend it. I can't 
> comment on the 
> specifics since I'm not familiar with how it more exactly 
> will be implemented 
> in libxslt. It will be interesting to see how it turns out.
> 
> Using specialized structures is how Saxon(and all 
> Saxon-derivatives) is 
> implemented. In my implementation of XQuery 1.0 and XPath 
> 2.0(and later on 
> hopefully also XSL-T 2.0).[1] I also take an approach of 
> using specialized 
> structures.
> 
> It is probably an implementation approach which makes even 
> more sense for the 
> second generation of these technologies because of the optimizations 
> implementations can do with the static typing, and the 
> increased requirements 
> of catching errors in XPath/XSL-T code at compile time.
> 
> For a user, an XSL-T stylesheet appears as an XML /document/, 
> but from an 
> implementation's perspective, a stylesheet is more of a list 
> of execution 
> instructions, where the closest one gets to XML is the "XML 
> literals" in 
> template bodies. For example, most "xsl:*" attributes are 
> settings, adjusting 
> how something should be carried out.
> 
> These are the advantages I see:
> 
> * Reduced memory usage. For example, there's a big difference 
> between storing 
> an xsl:if element with whatever attributes that happens to 
> appear, and a 
> struct that contains two pointers, one to a pre-compiled 
> XPath expression and 
> the other to a template body.
> 
> * More possibilities for the engine. When having specialized 
> representations 
> for XSL-T instructions, especially if they can be treated 
> identically to 
> XPath expressions, one can implement traditional compiler 
> optimizations/AST 
> rewrites.

Thank you for the comments! This is very appreciated.

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.

Regards,

Kasimier