[The more deeply I understand XSLT the more
I dislike it.]
I note that the XSLT "style" used in GN seems
to prefer xsl:include over xsl:import.
(The exception seems to be the harvesting code.)
I wonder if xsl:import should be used in most
places where xsl:include is currently used.
Here's an example of why I think this.
The file main-page.xsl has:
<xsl:include href="main.xsl"/>
Both main-page.xsl and main.xsl have definitions of this template:
<xsl:template mode="script" match="/">
According to the XSLT specification, (a) that's an error
(because they have the same priority), but (b) the XSLT
transformer is allowed to ignore the error as long as it
then chooses the last definition of the template.
I find that a very strange thing to say in a specification.
It seems that Xalan chooses to ignore the error and
selects the last definition of the template, which happens
to be the one in main-page.xsl. The result is that we
get the desired behaviour and no errors or warnings.
(I looked at the Xalan source code and it appears that
the check is marked as a "TODO".)
But a future version of Xalan, or a replacement XSLT
processor, might implement the check and thus reject
some of the XSLT code in GN.
(A quick test with Saxon shows that it detects the
error, flags it as a warning, and then chooses the
last definition.)
By using xsl:import instead of xsl:include, the
definition of the template in main.xsl has a lower
import precedence and is overridden by the definition
in main-page.xsl. We get exactly the same result,
but the key difference is that it's now correct XSLT
according to the specification.
Perhaps my concern is only theoretical, as no XSLT
transformer rejects (or will ever reject) a stylesheet
with conflicting definitions of the same template?
--
Richard Walker
Software Improvements Pty Ltd
Phone: +61 2 6273 2055
Fax: +61 2 6273 2082