This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: Functional programming in XSLT
- To: "Michael Kay" <mhkay at iclway dot co dot uk>
- Subject: Re: [xsl] Functional programming in XSLT
- From: Jeni Tennison <mail at jenitennison dot com>
- Date: Thu, 15 Mar 2001 05:07:34 +0000
- CC: xsl-list at lists dot mulberrytech dot com
- Organization: Jeni Tennison Consulting Ltd
- References: <000b01c0ac7b$8cc5c4e0$c5453c3e@oemcomputer>
- Reply-To: xsl-list at lists dot mulberrytech dot com
Hi Mike,
>> Alexey Gokhberg wrote:
>> The current proposal for <exsl:function> does not conform to this
>> rule. In particular, the <exsl:result> feature, with all rules
>> governing its use, looks a little bit odd for me.
>
> You're being polite, I think it's weird! Your <uxsl:define>, I
> think, is very close to my <saxon:function>.
Which are the bits that you think are particularly weird/hard to
implement/bound to cause trouble to newcomers to XSLT?
Personally, I think quite a lot of complication is added for very
little gain by allowing the template content of exsl:function to
generate result nodes, i.e. allowing:
<exsl:function name="foo">
<foo />
</exsl:function>
as a shorthand for:
<exsl:function name="foo">
<exsl:result><foo /></exsl:result>
</exsl:function>
The only other big difference with saxon:return (as I see it) is the
fact that exsl:result is allowed within xsl:for-each, but that makes
some things (e.g. keys in different documents) a lot easier.
But perhaps there's something more?
Cheers,
Jeni
---
Jeni Tennison
http://www.jenitennison.com/
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list