[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Perfomance: 'conditional instruction' vs. 'multi

Subject: Re: Perfomance: 'conditional instruction' vs. 'multi template'
From: "G. Ken Holman" <gkholman@xxxxxxxxxxxxxxxxxxxx>
Date: Sat, 03 Nov 2012 13:58:40 -0400
Re:  Perfomance: 'conditional instruction' vs. 'multi
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@xxxxxxxxxxxxxxxxxxxx Google+ profile: https://plus.google.com/116832879756988317389/about Legal business disclaimers: http://www.CraneSoftwrights.com/legal

Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.