RE: loosening restrictions on top-level conditionals/expressions

> In relation to a previous topic here ("conditionals not allowed at top
> level", 26 April 2001),  I would also like to request this 
> (or equivalent)
> functionality, in the form of allowing expressions within
> xsl:include/import, or allowing <xsl:element> to be used as a 
> top-level
> element.
> 
> Given the case where stylesheets are compiled from numerous 
> modules, and
> particularly my case, where the language of the modules 
> differ, it would be
> desirable to dynamically import/include stylesheet modules for that
> language.

The question is, what do you mean by "dynamically"? If you mean after the
source document is available, and perhaps changing in the course of
execution, then I think the answer is a definite no. Some other mechanism,
perhaps, for dynamically changing the set of rules that are "active"; but
not something that changes the stylesheet while it is executing.

If you mean some kind of pre-processing step, an operation performed on the
source stylesheet before it is compiled (and certainly before execution
starts), then that's a more tenable suggestion. Our response would be that
you can achieve this easily by applying transformations to stylesheets as
XML documents: many people do this. It would be possible to provide some
standard preprocessing directives, and a standard preprocessor that
processes them, but I would see this as being something outside the core
XSLT language definition.

> 
> Here is a brief example of what I would like to accomplish:
> 
> <!-- example document -->
> <document language="en">...</document>
> 
> <!-- solution 1, previously proposed -->
> <xsl:if test="language='en'">
> 	<xsl:include href="stylesheetModule_en.xsl"/>
> </xsl:if>

OK, this is dynamic, after the source document is available. It's definitely
not appropriate to think of this as an <xsl:include>. I would think of it
more as a dynamic enabling/disabling mechanism that activates sets of rules
at run-time, perhaps based on their mode.

One approach that has been suggested for achieving this, which is much
better aligned with the XSLT architecture, is dynamic selection of the
default mode:

<xsl:if test="language-en">
  <xsl:select-mode mode="english">
     <xsl:apply-templates/>
  </xsl:select-mode>
</xsl:if>

> 
> The next example could be accomplished by relaxing the 
> restrictions on the
> import/include elements (allowing expressions to be evaluated).
> 
> <!-- solution 2 -->
> <xsl:include href="concat('stylesheetModule_',{@language},'.xsl')"/>
> <!-- or, $lang supplied at run-time (e.g., command-line) -->
> <xsl:include href="concat('stylesheetModule_',{$lang},'.xsl')"/>

This is functionally equivalent, and has exactly the same problems. Allowing
a program to modify its own source text is something that has been known to
be a bad idea for about 40 years.
> 
> This final example could be accomplished by allowing 
> <xsl:element> to be
> used as a direct child of <xsl:stylesheet/transform>:
> 
> <!-- solution 3 -->
> <xsl:element name="xsl:include">

I've no idea what semantics you are thinking of here, perhaps it's just
another syntactic idea for dynamic inclusion.

I think in most cases the right answer to your problem is to use xsl:import,
with the special-purpose stylesheet modules importing the general-purpose
modules. You then decide which rules you want to apply at the time you
select one of the special-purpose modules as the principal stylesheet for
the transformation. This may mean splitting your transformation into
multiple phases if you can't make this decision until you'velooked at the
data.

Michael Kay

Received on Wednesday, 13 March 2002 08:55:21 UTC