[xsl] xsl:script: functions written in XSLT

Subject: [xsl] xsl:script: functions written in XSLT
From: Jeni Tennison <mail@xxxxxxxxxxxxxxxx>
Date: Tue, 9 Jan 2001 11:36:15 +0000
Hello all,

XSLT 1.1 introduces the xsl:script element as a means of defining
extension functions that can be used in XPath. The language in which
the user functions are defined is given with the 'language' attribute,
which can take one of the three standard values, 'ecmascript',
'javascript' or 'java', or a QName to indicate another language.

[Aside: HTML's 'script' element used to use a language attribute to
specify the scripting language, but this was deprecated in HTML4 in
favour of a 'type' attribute that gives a content-type style value
instead (e.g. text/javascript).  Presumably there were good reasons
for this (?) and if so, might XSLT be better off using 'type'
rather than 'language' from the start?]

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.

One big advantage of this would be that it would diminish the current
extremely verbose syntax for calling named templates.  Rather than
having to do:

  <xsl:variable name="intersection">
    <xsl:call-template name="intersection">
      <xsl:with-param name="set1" select="$set1" />
      <xsl:with-param name="set2" select="$set2" />
  <xsl:for-each select="$intersection">

I could do:

  <xsl:for-each select="set:intersection($set1, $set2)">

There could also be advantages in using XSLT rather than ECMAScript,
Javascript or Java, in that XSLT processors would all be able to
support it relatively easily (presumably) and that it would be able to
deal with nodes or node sets as arguments and return values, and with
navigating the source tree, in a way that the other languages probably
couldn't without some kind of extensions.

Any comments?

Jeni Tennison

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list

Current Thread