Re: [xsl] Functional programming in XSLT

Subject: Re: [xsl] Functional programming in XSLT
From: Jeni Tennison <mail@xxxxxxxxxxxxxxxx>
Date: Thu, 15 Mar 2001 11:59:55 +0000
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


Current Thread