RE: RE: syntax sugar for call-template
> > > <xsl:template name="foo"> > > > <bar> > > > <xsl:return select="'bar'" /> > > > </bar> > > > </xsl:template> > > > > I must say that I really do not like the "return" idea. > > > > Then how else do you write a function equivalent, say, to distinct() or > intersection() or max()? Named templates can only return trees, you need > something that can return arbitrary node-sets, numbers, strings, or > booleans. Mike, I do not like the idea of "return" inside a "template", I was only after an abbreviated method to call templates from within other templates; not call templates from within a xpath expr. If I had a need for calling a method from within XPath, then I *do* like your suggestion about a seperate "function" declaration for creating functions callable from Xpath. It makes sense to have it a seperate construct for the reasons I believe you pointed out: (a) currently templates do not support returing arbitrary node-sets, numbers, strings or booleans (b) arguments should be passed by position and not by value (c) functions don't need a "output" result fragment as templates already have. (d) this new function mechanism can be the same as the extension functions (only that the implementation is in XSLT). This is an *acceptable* rendition of the script idea, since I does not pollute XSLT with other languages. In short, I see the 'function requirements as completely different from the 'template requirements; and as such they should be seperate constructs. I belive this is your position isn't it? IMHO, trying to merge them will be FAQ heaven.... Kind Regards, Clark 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