On Wed, 2013-01-09 at 17:31 +0000, Michael Kay wrote:
Unfortunately there is no equivalent of super() that allows you to
invoke an overridden function from an overriding function.
This omission is being rectified in XSLT 3.0 (but not yet implemented in
Saxon).
Michael, thank you for the information. I do not know how fast we'll get
to stable implementations of XSLT 3.0 and how fast TEI will move to XSLT
3.0. So for the sake of seeing how someone who has to work with 2.0
could try to work around this limitation, let me list the solutions that
came to my mind.
I'm going to posit the following case:
- base.xsl defines a function named foo
- derived.xsl wants to override foo minimally.
I'm not dealing here with copyright issues, which could be problematic
with some of the solutions I'm listing.
In the following, the XML is all typed without the benefit of any
validation whatsoever. I've reread myself but egregious errors could
have slipped by.
1. The foo function in derived.xsl opens base.xsl and searches for the
foo function, parses it, and ...
Ok, this won't work without using extension functions or require so much
work that it would amount to writing an XSLT parser in XSLT.
2. Preprocessing. Create a file named derived-in.xsl which (roughly
speaking) contains something like:
<xsl:import href="base.xsl"/>
<xsl:function name="foo-base"/>
<xsl:function name="foo">
... do the work ...
... call foo-base when we want to use the old behavior of foo as
defined in base.xsl ...
</xsl:function>
From the derived-in.xsl stylesheet, use a preprocessor to create
derived.xsl which instead of having an empty foo-base stub, contains a
foo-base function which contains copy of the contents of the function
foo as it appears in base.xsl.
3. Have derived.xsl be created from base.xsl through an XSLT
transformation. This is similar to the previous solution but completely
eliminates the import relationship between derived.xsl and base.xsl.
Overriding behavior is not done through language mechanisms but by
rewriting XSLT code.
4. Functions as wrappers around templates. The file base.xsl contains:
<xsl:function name="foo">
<xsl:call-template name="foo"/>
</xsl:function>
<xsl:template name="foo">
... do the actual work ...
</xsl:template>
Whoever wants to override what the function foo does overrides the
template named foo. So derived.xsl contains:
<xsl:template name="foo">
... do the customized work ...
... use <xsl:apply-imports/> as needed ...
</xsl:template>
The downside of this solution is that it requires base.xsl to be
modified. Which means that whoever is responsible for it must agree to
make the changes.
Solution 4 is the one I prefer right now.
Thank you,
Louis
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--