This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
RE: Functional programming in XSLT
- To: "'Jeni Tennison'" <mail at jenitennison dot com>
- Subject: RE: [xsl] Functional programming in XSLT
- From: "Michael Kay" <mhkay at iclway dot co dot uk>
- Date: Thu, 15 Mar 2001 10:36:13 -0000
- Cc: <xsl-list at lists dot mulberrytech dot com>
- Reply-To: xsl-list at lists dot mulberrytech dot com
> >> 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?
I've just looked at your current spec, as I hadn't been following all the
fluctuations as it developed. I'm pleased to see that some of the weirder
things didn't make it in!
But there are still two things I don't much care for. One is the "implicit
result" of an RTF, I'd prefer people to write
<exsl:function ...>
<exsl:return>
<tree/>
</exsl:return>
</exsl:function>
rather than just
<exsl:function ...>
<tree/>
</exsl:function>
Yes, it's more verbose, but it's also more consistent, it means there's only
one way of doing it instead of two, it detects a class of user errors, and
in any case, I'm not sure returning RTFs is that important a use case.
Secondly, I don't like treating multiple exsl:result's as a "recoverable
error". I can't think of too many existing cases in XSLT 1.0 where people
are going to write stylesheets that depend on errors being recovered by one
processor, where they are going to have considerable difficulty fixing the
error if another processor chooses not to recover from it.
I still prefer having a static constraint on where <exsl:return> can appear,
but if you can't live with that, have a strict rule that only one may be
instantiated.
(And incidentally, I prefer "return" to "result". It's in tune with the
imperative style of other keywords such as call-template, apply-templates,
include, import.)
Mike Kay
Software AG
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list