Re: [xsl] Re: Designs for XSLT functions (Was: Re: RE: syntax sugar for call-template)

Subject: Re: [xsl] Re: Designs for XSLT functions (Was: Re: RE: syntax sugar for call-template)
From: Jeni Tennison <mail@xxxxxxxxxxxxxxxx>
Date: Tue, 20 Feb 2001 09:36:53 +0000
Dimitre Novatchev wrote:
>> 1.a. Using xsl:template vs. using exsl:function
> <xsl:function name="QName" p1="p1Name p1Default"
>                           ....................
>                           pN="pNName pNDefault"
>                                                   >
>     <!-- Contents here -->
> </xsl:function>   

So rather than using xsl:param, you'd like to be able to have
attributes in exsl:function, with the name of the attribute indicating
its order (for positional calling of parameters), and each taking two
space-separated values: a name and a default value.  Am I interpreting
your snippet correctly, Dimitre?

I think it would be useful to hear from implementers about the
practicalities of numbered attributes as suggested above and the ease
of parsing/interpreting the paired values that Dimitre suggests.

>> 1.b. Top-level declaration vs. declaration within xsl:script
> Doesn't matter. <xsl:script> implies that the contents is script
> (alien to XSLT). Therfore, not placing <xsl:function> within
> <xsl:script> may help avoid confusion.

[Aside: I think that xsl:script should be renamed to xsl:binding or
xsl:functions or something that *doesn't* imply script contents,
because I don't think its intention is that only script-type languages
(e.g. Javascript, VBScript) can be used within it.]

>> 1.c. exsl:return and/or result tree fragments
>   <xsl:return>
> But this does not exclude returning RTF. There would not be a RTF
> type in XSLT 1.1. It will be more correct to speak about
> "dynamically created nodes".
> Any variable that contains "dynamically created nodes" could be
> returned by <xsl:return>. Therefore, question 1.c is misleading --
> there will be no limitation on returning "dynamically created nodes"
> even only if <xsl:return> is allowed.

Sorry, yes.  The distinction I was making was between allowing the
return of values through exsl:return and the return of values as
simply the value given when the content of exsl:function is
instantiated.  So the distinction between:

<exsl:function name="my:func">
   <foo />


<exsl:function name="my:func">
      <foo />

All the arguments I've seen so far seem to have been in favour of only
allowing exsl:return.  If anyone out there feels that the former
should be allowed, then do speak up!

>> 2.a. exsl:function() vs. my:func()
> None of these.
> Just:
> fn()
> I think fn() must be a standard XSLT/XPath function -- these
> functions do not have a full QName.

Unfortunately, we are not in a position to introduce standard
XSLT/XPath functions.  Only those in the WG are, and only when new
versions of their standards come out.  We will move a lot quicker at
getting this functionality if we create an extension function for now,
which can later be moved into the XSLT namespace (and hence be

>> 2.b. Passing parameters by position vs. name
> fn(QName, p1="Name1 Value1",..., pN="NameN ValueN")
> This allows parameters to be passed by name (as above), 

This is a syntax that isn't allowed in XSLT 1.0.  That's not to say
that it wouldn't be a useful syntax to have, just that *we* cannot
make that change.



Jeni Tennison

 XSL-List info and archive:

Current Thread