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 11:59:55 +0000
- CC: xsl-list at lists dot mulberrytech dot com
- Organization: Jeni Tennison Consulting Ltd
- References: <000b01c0ad3b$cf4d4fc0$2d3a3c3e@oemcomputer>
- Reply-To: xsl-list at lists dot mulberrytech dot com
Hi Mike,
> 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!
Good, I'm glad it's not as bad as you feared.
> But there are still two things I don't much care for. One is the
> "implicit result" of an RTF
[snip]
> 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.
I'm in agreement. I'll make the change in the next version unless
someone comes up with a good reason why not.
> 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.
That sounds reasonable to me. I'm a bit wary of the recoverable errors
generally because of the portability problems that they create and the
complications it gives when testing compliance, as David Marston
pointed out.
I don't think that I can live without allowing exsl:result within
xsl:for-each, which means there has to be a dynamic constraint. We
could add static constraints like not having any elements following
the exsl:result within the exsl:function, unless they're xsl:fallback.
That would make sense, and also make the only place the dynamic
constraint really applies be within xsl:for-each.
I'll make this change in the next version too.
> (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.)
That's one vote for exsl:result (Uche) and one vote for exsl:return
(you). Any other opinions?
Cheers,
Jeni
---
Jeni Tennison
http://www.jenitennison.com/
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list