Re: XSLT 1.1 comments - the chocolate hobnob challenge

David Carlisle wrote:
> 
> I'd very much like to see a mechism for defining functions in XSLT. Not
> only to "save keystrokes" on the syntax of parameters to named templates
> (although that in itself would be fairly good reason) but rather because
> I can call functions inside deeply nested XPath expressions in ways that
> are really difficult using named templates and variables. So it seems to
> be extra functionality not just fewer keystrokes.
> 
That seems like a fine use case to me.

> But I'm not sure how much adding that would remove the need for
> external extension functions of the types currently used.
> If you use an external function to use a regexp handler
> or language aware date library, then you are unlikely to want to code
> that functionality in XSLT eiher as a function or a named template.
> 
I think there is an pretty substantial requirement for extension
functions that could be coded in XSLT - off the top of my head:

	simple math and string functions:
		eg cos(), sin(), last-index-of(), to-upper()

	set functions (obviously we're using XSLT 1.1 RTF conversion to
node-sets here):
		eg max(), min(), same-node() and various grouping functions 

> So I don't see that non xsl functions are "privileged". They are a
> necessary evil.
> 
They may well be a necessary evil - but they are also "privileged" in
the sense that I can write an extension function in java and expect all
processors that support xsl:script/@language='java' to run it, but I
can't do this for xslt ...
unless ... *light goes on* - could the xslt *community* define a mapping
for say, saxon:function style XSLT extensions?

> I don't suppose I get the biscuit for this reply (Are you going to
> provide a pint of Old Peculier to wash them down?)
> 
only if it's on draught at Keble College for XSLT-UK 01 ;)

Francis.

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list