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.
yes
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.
yes
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
alternatives.
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.
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--