Altova Mailing List Archives

Re: [xsl] [xslt 2.0] Difference betwen functions and templates

From: Abel Braaksma <>
Date: 7/19/2007 2:08:00 AM
Hi Justin,

This is a lot about whether you should create a method or a field in 
javascript, or a sub or a function on old basic, or a struct or a class 
in C++. Sometimes you can interchange them (a struct in C++ can be 
replaced by a class), sometimes not (a struct can have functions, but 
does not do encapsulation). Depending on your need, a programmer should 
choose what best suits his or her task. In the case of functions/named 
templates, this will depend on what the programmer needs:

  1. If you need an initial template, the only way is a named template

  2. If you need the current context node, the obvious choice is a 
named template

  3. If you want to mix both matching and calling of a template, you 
need a named/matching template

  4. If you need/want to use it inside an xpath expression, you likely 
choose a function

  5. If you want recursion, a function is probably easier

  6. If you want polymorphism (partially, only nr of arguments) you 
must use a function

  7. If all you need to do is act on a simple data type (not a node), 
you probably want a function

  8. If you like import precedence tricks, templates may be easier, 
because they don't error when they hit the same imp precedence

  9..... etc, I am sure this list can be extended beyond the horizon ;)

See my comments below.

Justin Johansson wrote:
Please correct me if I am wrong on this one :-

There is very little difference between the end result of executing an

XSLT 2.0 function or template.  That is, both generate a result sequence.

The difference is the context in which they may be invoked.



xsl:templates can, and must, be invoked within a sequence constructor either

via xsl:apply-templates (it the case of a match template) or xsl:call-template

(in the case of a named template)


You can cheat: if you place your template inside a function you can call 
your template from an xpath expression.

Don't forget about the initial template (-it on the commandline of 
saxon) and the mix: both named and matching template.

xsl:functions can, and must, be invoked from an XPath expression.



Consequently the use of call-template is extemely analogous to

invoking a function apart from the context in which the respective

constructs are called.  There are subtle differences in the declaration

of params for a template as opposed to a function.  There is also

a difference in the focus being initially defined for a (named) template

but not so for a function.


yes. Mainly, named parameters are not possible with functions, and the 
order is important when calling the function. With a named template the 
order is not important. All parameters are mandatory in a function 
(making it tedious if you want several parameters having a default, this 
means writing several function statements for all arities). Not so in a 
template, where a parameter can have a default and is optional (unless 
the required attr is set).

The bottom line is that named templates and functions are essentially

the same thing and it would have been possible for XSLT 2.0 to do

away with either xsl:call-template or xsl:function.


Maybe so, maybe not. See the list above. There are some occasions where 
I still favor call-template over a function call. This is of course a 
design issue and has much to do with clarity of the code, or 
readability. But in my experience, since XSLT 2.0, I have used 
call-template less and less.

The rationale for asking this question is that is generally a good idea
to eliminate choices (from the programmer) for the way something is
accomplished unless there are compelling reasons to provide the

This is not to suggest that XSLT 2.0 should be changed;  rather it is
to assist in writing an article of XSLT style guidelines.


Perhaps. I think that any good programmer should be able in making 
weighted choices. Poor programmers, or programmers learning a new 
language, are often best helped when they hit their head a couple times 
when making the wrong choices, instead of being told to so because of 
some guideline.

At the other hand, having a guideline with good argumentation, will help 
both good and poor programmers to increase their understanding of the 
subject, and still make up their own mind, of course.


These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.