9

I have basic query. I have been using xsl:template and use call tempate to make recursive calls to the template. I see xsl:function which also has feasibility to make recursive function calls like recursive template calls and achieve the same. When should xsl:function be used and when should xsl:template be used. I am not sure what is the diffence between the two and when should they be used. What are their special features of each of them. Can someone please help me understand this better.

Rachel
  • 763
  • 14
  • 29

4 Answers4

7

This is how I replied to a similar question almost 3 years ago:

Benefits of using <xsl:function/>:

  1. Composability.

  2. Looks great in an expression which uses it as a parameter, as return value or as a partial application.

  3. Readability (compactness) and maintainability.

  4. More loose coupling (does not depend on an implicit context node)

  5. Can be referenced in an XPath expression

Shortcomings:

  1. Parameters are identified only by position (not by name)

  2. Can be impure (can have a side effect, such as creating new node(s)) and just by looking at an expression referencing this function people may not understand that it has a side effect. However this possibility of confusion can be eliminated if proper naming is used.

I tend always to use <xsl:function/>. In the cases when the function creates new node(s) I follow the convention of starting its local-name with the string "make", as in makePerson().

I can only add to this:

Always when possible use <xsl:function>.

In XPath 3.0 functions are a first-class data type of the language (aka HOF -- Higher-Order Functions). They can be passed as parameters or returned as the result to/from other functions.

This is an incredibly powerful leap forward from using named templates.

Brett Zamir
  • 14,034
  • 6
  • 54
  • 77
Dimitre Novatchev
  • 240,661
  • 26
  • 293
  • 431
2

Conceptually xsl:apply-templates is a map with a polymorphic function expressed for all the rules you have declared. xsl:function declares a "regular" function you can use in any any other instruction or declaration accepting XPath expressions. xsl:call-template instruction "invokes" a particular named template (you could think of this as a function in some way).

Because this, there are differences about how evaluation context is involve in each one: xsl:apply-templates define a new context list from which the context node is taken as well as the proximity position; xsl:function doesn't have context node defined (it's an error to rely on it); xsl:call-template doesn't change the evaluation context.

Other evident difference is their relationship with the output: both xsl:apply-templates and xsl:call-template as XSLT instructions output their constructed sequence; xsl:function as part of an XPath expression it doesn't.

  • @Alejandro: I find two statements in your answer which are problematic (not exactly true). 1) "`xsl:function` doesn't have context node defined (it's an error to rely on it); " It is more exact to say thet the XSLT processor must signal an error if a relative XPath expression is encountered in the body of the function. 2) "xsl:function as part of an XPath expression it doesn't. (output a constructed sequence)". This is not true. An `xsl:function` can create nodes and return them -- I use this technique. Yes, an `xsl:function` can have side effects. – Dimitre Novatchev May 02 '11 at 13:18
  • @Dimitre: From http://www.w3.org/TR/xslt20/#stylesheet-functions _"Within the body of a stylesheet function, the focus is initially undefined; this means that any attempt to reference the context item, context position, or context size is a non-recoverable dynamic error."_ About two: it's not the function that is outputting to the result tree, but the XSLT instruction. About side effects, well, it could be disputed: even functions that construct new nodes as result will construct the same result for the same argument, besides that it might not have the same node identity. –  May 02 '11 at 14:08
  • @Dimitre: Of topic: it looks like there was a major retag that changed all `xpathengines` tags for `xpath` even changing the attribution for the edition (if I tagged with `xpathengines` now it says that I've tagged it with `xpath`). Follow the discussion at http://meta.stackexchange.com/questions/89005/what-did-happen-with-xpathengines-and-xqueryengines-tags –  May 02 '11 at 14:16
  • @alejandro: When a function returns the generate-id() of the constructed node, it returns diffirent result for the same argument -- on every call. – Dimitre Novatchev May 02 '11 at 14:38
  • @Dimitre: That's what I've said: it returns the same nodes (deep equals) but they **might** not have the same identity (Do note that there is not guaranteed in either way. In some spec this statement is explicit.) That doesn't dispute the fact that you can declare a no stable function and (like in any declarative language) you can safely model this through monoids. –  May 02 '11 at 15:59
  • @Alejandro: You said "About two: it's not the function that is outputting to the result tree, but the XSLT instruction." I didn't expect such a statement from you -- please think again. Your answer needs correcting -- as it is now it can be misleading and as a whole it is not true. I am expecting that you'd correct the answer so that it wouldn't need to be downvoted. – Dimitre Novatchev May 02 '11 at 16:48
  • @Dimitre: Don't you agree that there is a difference between XPath expression scope and XSLT instructions scope? Although the sequence construction model and undifferentiated use between `@select` and sequence constructors in XSLT 2.0 could blur this a bit. –  May 02 '11 at 17:02
1

I found Dimitre's response - http://www.stylusstudio.com/xsllist/200811/post00400.html - helpful.

Benefits of using <xsl:function/>:

  1. Composability.

  2. Looks great in an expression which uses it as a parameter, as return value or as a partial application.

  3. Readability (compactness) and maintainability.

  4. More loose coupling (does not depend on an implicit context node)

  5. Can be referenced in an XPath expression

Shortcomings:

  1. Parameters are identified only by position (not by name)

  2. Can be impure (can have a side effect, such as creating new node(s)) and just by looking at an expression referencing this function people may not understand that it has a side effect. However this possibility of confusion can be eliminated if proper naming is used.

I tend always to use <xsl:function/>. In the cases when the function creates new node(s) I follow the convention of starting its local-name with the string "make", as in makePerson().

Mads Hansen
  • 63,927
  • 12
  • 112
  • 147
Naraen
  • 3,240
  • 2
  • 22
  • 20
0
Templates are useful when you have the requirement to store the results of each recursion into a variable as a attribute ( at the end of each recursion before calling the next ).

**Example:**

    <xsl:variable name="test">
     <record>
        <xsl:call-template name="templateRecursion">
              <xsl:with-param name="xyz" select="xyz"/>   
        </xsl:call-template>
     <record>
    </xsl:variable>

**templateRecursion:**

    <xsl:template name="templateRecursion">

    <!-- Do processing -->
     <xsl:attribute name="" value=""

    </xsl:template>

So, the variable test will have 

    <record>
     <attribute_name="" value=""/>
      .
      .
    </record>
user3622009
  • 1
  • 2