> | 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>
> 
> I agree with Michael on this.

Yes.  I'm not sure I remember who disagreed.

> | Secondly, I don't like treating multiple exsl:result's as a "recoverable
> | error".
> 
> I agree witih Michael on this, too.

Ditto.

> | 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.
> 
> A rule that only one can be instantiated seems workable to me.

Yes.  I think it should be a dynamic constraint.

> | (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.)
> 
> I also prefer "return". It's more "verby", as M.K. notes, in the
> XSLT naming style.

I'm not sure where this idea comes from.  exslt:result sets a value for data, 
and everywhere else in XSLT that this sort of thing is done, it is declarative 
rather than imperative.  Therefore we have xsl:variable and xsl:param rather 
than xsl:let or xsl:set.  We have xsl:key rather than xsl:index.

If congruence with the rest of XSLT is the benchmark, I think exslt:result 
wins hands down.


-- 
Uche Ogbuji                               Principal Consultant
uche.ogbuji@xxxxxxxxxxxxxxx               +1 303 583 9900 x 101
Fourthought, Inc.                         http://Fourthought.com 
4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA
Software-engineering, knowledge-management, XML, CORBA, Linux, Python



 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list