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

["Abel Braaksma (online)" <abel.online@xxxxxxxxx>]

>> <!-- output will then be -->
>> mod:dog: Bark! I am a dog
>> mod:cat: Meow! I am a cat
>
> Not quite - that should really be "mod:animal::say-name()" called
> twice to be polymorphism - you're calling the "concrete" method
> there rather than the abstract.

Uhuh, bad example.... I should actually have a list of mod:animal
which contains both cats and dogs. Then loop the list and call the
fu:say-name() method. Then it would resemble the OO paradigm better.

>
> So why is this polymorphism?  Because the common Animal.xslt will
> use the $name variable depending on how the transform was
> constructed. You call "sayName" in the Animal stylesheet and that
> uses the $name variable in the Dog/Cat stylesheet.

I see what you mean and yes, i agree on that it is a (basic form of)
polymorphism.

>
> The Animal stylesheet is kind-of abstract in that it won't run on
> it's own because it lacks a declaration for $name.
>

That is indeed the way I use it now, especially in browser based
XSLT 1.0 (not sure why I encounter it less with XSLT 2.0 on the
server side).

To follow-up on your example using variables, i tend to use the
following construction when I *do* use it with XSLT 2.0 (not avail.
in 1.0). This raises an error when you fail to 'overload' the
variable in your importing stylesheet:

<!-- animal.xslt -->
<xsl:param name="name" required="yes" />

at least you get an error if the dog.xslt or cat.xslt (i.e., the
concrete 'classes' derived from this 'abstract' one) do not specify
the $name parameter. Even better, I use a variable instead as a
'best practice', because the param should not be settable or visible
from the outside (information hiding, haha):

<!-- dog.xslt -->
<xsl:variable name="name" select=" 'dog' " />


Cheers,
-- Abel Braaksma