Re: Designs for XSLT functions (Was: Re: RE: syntax su

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