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: xsl-list at lists dot mulberrytech dot com
- Subject: Re: Designs for XSLT functions (Was: Re: [xsl] RE: syntax sugar for call-template)
- From: Uche Ogbuji <uche dot ogbuji at FourThought dot com>
- Date: Mon, 19 Feb 2001 09:36:58 -0700
- Reply-To: xsl-list at lists dot mulberrytech dot com
> >> 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.
That's what I get for responding as I read rather than digesting the whole
post first. Of course you're right, and I'll moot for exsl:function.
> >> 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).
Well, if it does make it into the language, I agree. But even if it does, it
will take a while, and I wouldn't want these function extensions to be
dependent on XSLT 1.1 anyway.
> > 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.)
Agreed. I think it should always take named parameters.
--
Uche Ogbuji Principal Consultant
uche.ogbuji@fourthought.com +1 303 583 9900 x 101
Fourthought, Inc. http://Fourthought.com
4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA
Software-engineering, knowledge-management, XML, CORBA, Linux, Python
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list