Mike Brown wrote:
<exslt:include-compiled-module href="hrefToCompiledStylesheet"/>
is slightly more precise in meaning.
It would not be usable in XSLT 1.0 because top-level elements cannot be
extensions, and as I mentioned already, a 1.0 processor could not be expected
to conditionally ignore xsl:include/import instructions.
I'm still trying to wrap my head around how this might work in XSLT 1.0.
<xsl:template match="/">
<xsl:if test="element-available('exslt:include-compiled-module')">
<!--
side-effect: stylesheet tree gains top-level elements from
the compiled stylesheet. (at what import precedence?)
-->
<exslt:include-compiled-module href="hrefToCompiledStylesheet"/>
</xsl:if>
...
</xsl:template>
This might work for me. It would require the processor to re-do its
compile-time validation of the stylesheet tree, which I guess is doable,
though we may have to sacrifice some of the optimizations we made while under
the assumption that the stylesheet tree would not be modified at run time.
If I wanted to fall back on templates from an uncompiled sheet, I still could
not avoid loading that sheet via xsl:include or import, and there would be a
risk of template conflicts if done via includes. Also, by using an extension
element, there is no longer an association being made between the compiled and
uncompiled stylesheet hrefs. I thought that if you want to treat this as an
optimization option, you'd want the uncompiled stylesheet to be overridden
somehow. Maybe add an optional attribute, like
<exslt:include-compiled-module href="hrefToCompiledStylesheet"
overrides-href="hrefToUncompiledStylesheet"/>
I think this would address my concerns.