Mailing Lists Mail daktapaal@xxxxxxxxx
<mailto:xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
dinsdag 24 juni 2014 4:01
Very Logically True. Thanks Abel.
Just a quick clarification..
when I meant intuitive with approach1, I gave a wrong example..
I meant something like :
<xsl:template match="/">
<xsl:apply-templates select = b_xpath_to_cb/>
</xsl:template>
<xsl:template match="c">
<xsl:value-of select="."/>
</xsl:template>
Still, it is less flexible in most situations: if the path to "c"
changes, you need to change your stylesheet. If you want to match
multiple "c" elements at different paths, you need to create a
potentially complex XPath select expression. Also, it is not possible to
override with an xsl:apply-imports, making it harder to extend your
stylesheet. None of that is needed if you just let the processor do the
job for you.
But there are exceptions to this rule. Which one you choose is up to the
task at hand. For the trivial examples you gave, the template-based
approach is simplest and is easiest to maintain.
Dont you think it is more intuitive to say :
1. "Go Process all the c nodes at the xpath_to_c"
Than to say
2. visit *every* node and delete it if you dont find a matching node
The processor will visit every node anyway, because it must load the
whole document to find out whether it is well-formed and valid XML. In
XSLT, the general tendency is that it is more future-proof to choose the
2nd approach, because it lets you change the stylesheet by adding
templates, the 1st approach requires more work to change and maintain if
you want to process other nodes as well, and before you know it, your
program starts to look like a C-style imperative program and becomes
(very) hard to maintain.
Dont you think the option1 above is direct to the point, if that is
what I want? If there are 1000s of nodes in the document tree, then
dont you think it will take one hell of a time to visit
*each_and_every* node and deleting it, if the node is not matched..
Some how pointing it to the right xpath makes more efficient sence?
No. Several papers on this subject have shown in the past that it makes
hardly any difference, often no difference at all because other aspects
(size of document, parsing XSLT, parsing XPath) take more time than the
processing itself. The processors in existence are very efficient to do
processing it in this way. Even if it's millions of nodes.
It is not deleting it from the source tree, it is _not_ creating a node
in the result tree, which is a difference. If it was changing the XDM
(the DOM for XSLT/XPath processing), it would be slow, but that's not
how it works internally: a new tree is created instead.
You can search online for papers on "push vs pull stylesheets" (here are
two: http://www.ibm.com/developerworks/library/x-xdpshpul.html, and:
http://www.eddiewelker.com/2008/11/25/push-style-xslt-vs-pull-style/) .
There are several discussions available that explain the difference.
There are certain situations where pull style can be beneficial, but in
most situations, push style should have your natural preference. You
don't need xsl:for-each, hardly ever need xsl:if etc etc if you use push
style (approach #2), because the processor does the work for you and is
very good at it. With push-style (your #1) you preselect the set of
nodes to process (and be aware: for this preselecting, the processor
_also_ has to visit each/most node(s) to find out it matches your
select-expression), and after the preprocess (the selection) it is going
to be processed again (the apply-templates).
In my experience, it's just more natural and efficient in 9 out of 10
cases to use push-style (but I'm sure there is someone on this list that
can come up with an example where pull-style is better, but at the
moment, I cannot think of one).
It is also a well-known fact that people coming from imperative
languages (C, C#, VB, Java, JavaScript, Ruby, PHP etc) tend to choose
pull-style because that is the way they think, and push-style requires a
change in thinking.
Cheers,
Abel
Dak.T
On Mon, Jun 23, 2014 at 8:01 PM, Abel Braaksma (Exselt)