Re: [xslt] Changes of internal structures

[Frans Englich <frans englich telia com>]

Thought some more on this.

On Wednesday 05 April 2006 10:52, Kasimier Buchcik wrote:
> 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.

Couldn't it be useful to in the case of where the stylesheet is needed as an 
input document(that is, 'document("")'), to then simply load the stylesheet 
as a regular input document. My point is that the stylesheets which processes 
themselves are very rare(imho), and therefore the implementation can do 
compilation approaches that gains the vast majority of cases, at the cost of 
loading the xsl file in the rare cases it's needed. Also, document("") isn't 
as bad as actually compiling a stylesheet since it doesn't process 
xsl:include/import.

Would this break any stability constraints? Or is there anything else which 
would make it a bad idea?


Cheers,

		Frans