Re: [xslt] Changes of internal structures

[Frans Englich <frans englich telia com>]

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.


Random thoughts,

		Frans

1.
KDE code, hopefully released in KDE 4.0. Not done, but the code is fairly 
documented:

http://websvn.kde.org/trunk/kdenonbeta/kdom/xpath
svn://anonsvn.kde.org/home/kde/trunk/kdenonbeta/kdom/xpath