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> 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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
[xsl] Re: Designs for XSLT function, Dimitre Novatchev | Thread | Re: [xsl] Re: Designs for XSLT func, Dimitre Novatchev |
Re: Designs for XSLT functions (Was, Jeni Tennison | Date | Re: [xsl] apply-imports, Ruben Inoto |
Month |