Re: Designs for XSLT functions (Was: Re: RE: syntax su
> >> 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
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format