RE: [xsl] xsl:script: functions written in XSLT

Subject: RE: [xsl] xsl:script: functions written in XSLT
From: "Kaganovich, Yevgeniy (Eugene)" <ykaganovich@xxxxxxxxxxx>
Date: Tue, 9 Jan 2001 17:23:10 -0800
: What I've been wondering is whether it would be useful to allow people
: to define extension functions *in XSLT* within the xsl:script element,
: in a similar way to saxon:function. Perhaps named templates within the
: xsl:script element could be interpreted as extension functions, with
: parameters being arguments defined in order. The returned value could
: either always be a node set (which could be evaluated to give a
: string, boolean, number or whatever) or something like saxon:return
: could be introduced to return other value types.

Wow, so many yesses... I guess I'll have to be the devil's advocate :)

I was wondering about this when I first saw saxon:function : Is there really
any difference between that and named templates? If not, then why do we need
both? should re-think why it is we need saxon:function separately from
xsl:call-template; not that it causes any problems, but it just bothers me
that there is a need for two different syntaxes that essentially do the same

It seems to me terseness was never a high priority in XSLT; One can always
use XSLScript it it's so important... Actually, the convention for
abbreviated syntax in xslt is quite strange: for instance, why is it ok to
comma-separate arguments in a function call, but not in an attribute? Is
there something inherently wrong with <xsl:call-template name="go"
with-params="$p1, $p2"/> ?

To allow xsl:script equivalent using existent xsl:template syntax, why can't
we just use something like xsl:go($p1, $p2). Is it because xsl:call-template
has used up the xsl: namespace? Is there something inherently wrong with
assuming that xsl:go is supposed to invoke a template with name "go". If so,
how about xsl:function:go($p1, $p2) ? (being semi-serious here, I know
inheritance in namespaces has been an issue...) Maybe the safest thing to do
would be to come up with another namespace for XSL functions, and call
xsl-function:go($p1, $p2) ?

Alternatively, we can define an XSLT function call-template() to accept the
template name as the first parameter and the template params as the rest:
<xsl:value-of select="call-template('go', $1, $2)"/>

I suppose since we have xsl:script anyway, we might as well use it, but then
do we really need the form of xsl:template that takes a name? Yes, I know
they can have a match as well as a name and be kinda overloaded, but what's
the point of it? I think the code would look cleaner if the templates were
separated into two anyway, one with match, one with a name. And btw,
xsl:script doesn't do anything for verbosity of when invoking the
<xsl:template match="..."/> form with parameters...

I want to be clear here, I don't think there's anything wrong with Jeni's
suggestion in itself, but it seems that either we don't really need this, or
there's something wrong with why we do.

- Eugene

 XSL-List info and archive:

Current Thread