[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Functional programming in XSLT

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

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.