xsl-list
[Top] [All Lists]

Re: [xsl] node() function

2014-06-24 04:16:50


Mailing Lists Mail daktapaal(_at_)gmail(_dot_)com <mailto:xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com>
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 = “_xpath_to_c”/>
</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)

--~----------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
EasyUnsubscribe: http://lists.mulberrytech.com/unsub/xsl-list/1167547
or by email: xsl-list-unsub(_at_)lists(_dot_)mulberrytech(_dot_)com
--~--

<Prev in Thread] Current Thread [Next in Thread>