This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: Designs for XSLT functions (Was: Re: RE: syntax sugar for call-template)
- To: Uche Ogbuji <uche dot ogbuji at FourThought dot com>
- Subject: Re: Designs for XSLT functions (Was: Re: [xsl] RE: syntax sugar for call-template)
- From: Jeni Tennison <mail at jenitennison dot com>
- Date: Mon, 19 Feb 2001 08:58:54 +0000
- CC: xsl-list at lists dot mulberrytech dot com
- Organization: Jeni Tennison Consulting Ltd
- References: <200102190510.WAA11485@localhost.localdomain>
- Reply-To: xsl-list at lists dot mulberrytech dot com
Hi Uche,
> As it is, I am very interested in experimental implementation of
> these ideas in 4XSLT.
That's great :)
> I hope that I and my fellow implementors who are interested in these
> ideas can all agree on a single NSRef for this set of extensions. I
> have the opentechnology.org domain available. If this is amenable,
> how about
>
> xmlns.opentechnology.org/common-xslt-extensions
Ah good, I was hoping someone would come up with a namespace :) That
one looks fine by me, but if there are any other offers (or objections
to the above) it would be great to have them on the table.
>> Arguments for xsl:template include:
>> i. it already exists
>> ii. it might then be possible to have a template that was used both
>> with normal xsl:call-template syntax and as a function (though
>> it's arguable whether this is desirable).
>
> Well, the nice thing about this is that it would be easy to call
> existing named templates with the new syntax. Also, one could set up
> a single template for import into both regular transforms and ones
> that use exsl:function.
Aside from the fact that there would be a massive conflict with your
stated preference for *only* exsl:return. If only exsl:return were
allowed, there would be no way to have a regularly called template and
a function template.
>> 1.b. Top-level declaration vs. declaration within xsl:script
>
> As they say in teen movies: "don't even go there".
>
> To be more precise, I vote firmly for top-level. Surprise surprise.
> Perfectly legal under XSLT 1.0, so why not?
I admit that the rationale for xsl:script is weak if we're only
talking about user-defined functions in XSLT. One plausible rationale
would be, if we have functions declared with xsl:template, that it
could indicate which xsl:template elements have to comply with the
function rules (e.g. contain exsl:return, not generate any nodes).
*If* the xsl:script element is accepted into the XSLT 1.1 canon
(leaving aside whether it should be or not), I think it is more
logical to place function definitions in XSLT in xsl:script than at
the top level, so that it mirrors the definitions of functions in
other languages. It would also allow XSLT-defined functions to act as
a fallback when the implementations in other languages have failed (as
long as implementers implement support for exsl:xslt as an xsl:script
language).
> But I do think we should allow RTFs as follows:
>
> <exsl:function name="my:func">
> <xsl:choose>
> <xsl:when test="$i-want-my-rtf">
> <exsl:return>
> foo
> </exsl:return>
> </xsl:when>
> <xsl:otherwise>
> <exsl:return select="'foo'" />
> </xsl:otherwise>
> </xsl:choose>
> </exsl:function>
>> 2. Calling Functions
>> --------------------
>>
>> 2.a. exsl:function() vs. my:func()
>
> I think we can have both, but I'd rename exsl:function to exsl:call.
Ah good, I didn't like exsl:function() as a name.
>> 2.b. Passing parameters by position vs. name
>
> Again allow both, but this time by allowing tricks with exsl:call.
>
> The first exsl:call parameter is the function qname. An even number
> of further parameters is permitted, and if so, these are the named
> parameters.
So exsl:call() would *always* take named parameters - always have an
odd number of arguments in total - the function name and then paired
parameters? Whereas my:func() *always* passes parameters by position
(and could therefore have any number of arguments). (Just wanted to
make that clear - I think that allowing both position and name in the
same kind of call will lead to trouble.)
Cheers,
Jeni
---
Jeni Tennison
http://www.jenitennison.com/
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list