But templates in the importing stylesheet that match have absolute priority
over those in the imported stylesheet, so a declarative stylesheet that imports
another stylesheet would have the same effect whether the imported stylesheet
was declarative or imperative, wouldn't it?
For example:
<import href="imperative.xslt">
<template match="thenode[child::x]">
... do_this ...
<template>
Would have the same effect as
<import href="declarative.xslt">
<template match="thenode[child::x]">
... do_this ...
<template>
Are they any cases where these would produce different results?
Certainly in the general case it's probably harder to understand what the
override will do when the imported stylesheet is imperative, but you can use
declarative template to override an imperative one.
In the past I've used declarative stylesheets to import and fix imperative
stylesheets that I wasn't allowed to change.
Dan
-----Original Message-----
From: G. Ken Holman [mailto:g(_dot_)ken(_dot_)holman(_at_)gmail(_dot_)com] On
Behalf Of G. Ken Holman
Sent: Saturday, November 03, 2012 1:59 PM
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com;
xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
Subject: Re: [xsl] Perfomance: 'conditional instruction' vs. 'multi template'
At 2012-11-03 16:24 +0100, Norbert Heidbrink wrote:
if a node is to be processed differently, depending on a certain
condition, there are two approaches.
Let's say, the condition is "existance of child x".
Approach 1: two templates with different matching XPaths
<template match="thenode[child::x]">
... do_this ...
|
</template>
<template match="thenode[not(child::x)]">
... do_that ...
|
</template>
Approach 2: one template with a conditional instruction
<template match="thenode">
<xsl:choose>
<xsl:when test="x">
... do_this ...
|
</xsl:when>
<xsl:otherwise>
... do_that ...
|
</xsl:otherwise>
</xsl:choose>
</template>
I wonder, if one of these approaches is to be favoured?
Are there any severe implications on performance?
Any other advantages / disadvantages that speak in favour of approach 1
or approach 2?
I am curious to read your estimations,
I am not an implementer, just a user, but this is how I see it and teach it.
Approach 1 allows the processor to optimize the method by which it decides
between the two template rules each with a template to build the result tree.
Approach 2 burdens the processor to execute your own determination of how to
choose between the two templates to build the result tree.
Approach 1 is declarative, approach 2 is imperative.
Approach 2 may be more intuitive to classical programmers, approach 1 may be a
bit harder for classical programmers to wrap their heads around.
Approach 1 can be exploited by an importing stylesheet in order to effect
nuanced differences in the stylesheet for one of the two template rules, even
when the imported stylesheet is read-only. Approach 2 prevents nuanced
overriding of only one of the two templates and imposes the burden on the
importing stylesheet to replicate the behaviours of the other template already
in the imported stylesheet that don't need to change.
For these reasons, especially the last one, I tell my students approach 1 is
"better" and approach 2 has drawbacks. I always try to write my stylesheets so
that in the future I can better exploit the stylesheet without changing it,
even if I don't yet know what those future requirements might be. That allows
me to continue using the unchanged stylesheet wherever I am using it, and yet
leverage it for other reasons in other contexts by the importing stylesheet
selectively changing behaviours. Top-level constructs can be overridden in
their entirety, while their contents cannot be selectively overridden. The
more template rules I have, the more nuanced I can change the behaviours. The
fewer template rules I have, the less flexibility I have to override smaller
portions of the imported stylesheet.
I hope this helps.
. . . . . . . . . . Ken
--
Contact us for world-wide XML consulting and instructor-led training Free
5-hour lecture: http://www.CraneSoftwrights.com/links/udemy.htm
Crane Softwrights Ltd. http://www.CraneSoftwrights.com/s/
G. Ken Holman mailto:gkholman(_at_)CraneSoftwrights(_dot_)com
Google+ profile: https://plus.google.com/116832879756988317389/about
Legal business disclaimers: http://www.CraneSoftwrights.com/legal
--~------------------------------------------------------------------
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>
--~--
--~------------------------------------------------------------------
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>
--~--