[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: xsl:script: functions written in XSLT

Subject: RE: xsl:script: functions written in XSLT
From: "Kaganovich, Yevgeniy (Eugene)" <ykaganovich@xxxxxxxxxxx>
Date: Tue, 9 Jan 2001 17:23:10 -0800
xsl script parameter
: 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
thing! 

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:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.