This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
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