[XSL-LIST Mailing List Archive Home]
[By Thread]
[By Date]
Re: Designs for XSLT functions (Was: Re: [xsl] RE: syntax sugar for call-template)
Subject: Re: Designs for XSLT functions (Was: Re: [xsl] RE: syntax sugar for call-template) From: Uche Ogbuji <uche.ogbuji@xxxxxxxxxxxxxxx> Date: Mon, 19 Feb 2001 09:36:58 -0700 |
> >> 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@xxxxxxxxxxxxxxx +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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: Designs for XSLT functions (Was, Jeni Tennison | Thread | Re: Designs for XSLT functions (Was, David . Rosenborg |
Re: Designs for XSLT functions (Was, Uche Ogbuji | Date | Re: [xsl] news, David Carlisle |
Month |