Re: Re: [xsl] Importing compiled stylesheets

> Dimitre Novatchev wrote:
> 
> > Then this is certainly a good candidate for:
> > 
> >      <exslt:include-compiled-module href="hrefToCompiledStylesheet"/>
> > 
> > 
> > Any opinions from the exslt mailing list?

Colin Paul Adams wrote:
> You can use element-available within
> xsl:when to test for the availability of the 
> exslt:include-compiled-module instruction, and, if it's not available, 
> fall back on normal xsl:include 

xsl:include is a top-level element that is typically evaluated at 'compile' 
time. You can't make its evaluation depend on a run-time condition.

Jirka Kosek wrote:
> Wouldn't it be better to create custom attribute for xsl:include. Like:
> 
> <xsl:include href="uncompiled.xsl"
>               exsl:compiledStylesheetLocation="hrefToCompiledStylesheet"/>

Extension attributes can't change the fundamental behavior of an XSLT
instruction. Michael Kay calls this example an optimization, but I don't
see how you can get around processing uncompiled.xsl if you follow the
spec to the letter. The presence of the extension attribute shouldn't
make xsl:include ignore the href.

However, I think it can be rationalized as long as we say that the base URI of 
the included stylesheet must be based on the regular href, not the extension 
attribute. 

I would prefer exsl:compiled-stylesheet-href for the name of the attribute.

Michael Kay wrote:
> The question here is not so much what counts as compilation,
> but whether the compiled representation can be saved to disk.

No, disk has nothing to do with it. The compiled representation must merely be 
referenceable by a URI, regardless of its format or where & how it is stored, 
and the processor must be able to recognize that URI as being the stylesheet 
to include. Even if the compiled sheet is never serialized as bytes and is not 
accessible via a URI resolver, all that matters is that its identifier is 
meaningful to the application and can be dereferenced in whatever manner is 
appropriate for the way in which it has been stored. This may require some 
custom URI resolution, but URI resolver plugability is a standard feature of 
most XSLT processors, no?

Re: implementations, add ours to the list. 4Suite supports compiled 
stylesheets -- they are pickled Python objects -- although it should be noted 
that our stylesheet reader is now so fast that it is actually *less* efficient 
to use these 'compiled' stylesheets than it is to let the processor read raw 
XSLT from a memory or file system-based stream ... unless you're dealing with 
ginormous, multiple external entity-laden sheets like DocBook XSLT.

-Mike