This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: Re: Designs for XSLT functions (Was: Re: RE: syntax sugar for call-template)
- To: xsl-list at lists dot mulberrytech dot com
- Subject: Re: [xsl] Re: Designs for XSLT functions (Was: Re: RE: syntax sugar for call-template)
- From: Jeni Tennison <mail at jenitennison dot com>
- Date: Tue, 20 Feb 2001 09:36:53 +0000
- CC: Dimitre Novatchev <dnovatchev at yahoo dot com>
- Organization: Jeni Tennison Consulting Ltd
- References: <20010220052635.10680.qmail@web6304.mail.yahoo.com>
- Reply-To: xsl-list at lists dot mulberrytech dot com
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>
and:
<exsl:function name="my:func">
<exsl:return>
<foo />
</exsl:return>
</exsl:function>
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
unprefixed).
>> 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.
Cheers,
Jeni
---
Jeni Tennison
http://www.jenitennison.com/
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list