This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: Designs for XSLT functions (Was: Re: RE: syntax sugar for call-template)
- To: David dot Rosenborg at pantor dot com
- Subject: Re: Designs for XSLT functions (Was: Re: [xsl] RE: syntax sugar for call-template)
- From: Jeni Tennison <mail at jenitennison dot com>
- Date: Mon, 19 Feb 2001 17:36:49 +0000
- CC: xsl-list at lists dot mulberrytech dot com
- Organization: Jeni Tennison Consulting Ltd
- References: <H000006d0001f41d.0982600996.stan.pantor.com@MHS>
- Reply-To: xsl-list at lists dot mulberrytech dot com
Hi David,
Thanks for the input.
> <!ELEMENT xsl:function (xsl:param*, xsl:variable*, xsl:return)>
Personally, I think that this is too restrictive. As you point out,
it makes ifs and chooses quite difficult. I'd prefer something along
the lines of:
<!ELEMENT exsl:function (xsl:param*, (xsl:for-each | xsl:if |
xsl:choose | xsl:message |
xsl:fallback | exsl:return)*)>
with multiple exsl:returns allowed in different xsl:whens, for
example.
> Another thing: wouldn't <xsl:result> be a better name for
> <xsl:return> (assuming it can only appear once)? At least to me it
> sounds more declarative.
I think we've been assuming that there's more than one, as above, but
I personally have no strong feeling either way about the name.
But this sparked something for me - having an exsl:return inside a
xsl:for-each:
<xsl:for-each select="$node">
<xsl:if test="*">
<exsl:return select="true()" />
</xsl:if>
</xsl:for-each>
(in effect equivalent to <exsl:return select="boolean($node[*])" />)
Perhaps xsl:for-each shouldn't be allowed directly within function
definitions? Can anyone come up with a use case where it's helpful to
have it?
Cheers,
Jeni
---
Jeni Tennison
http://www.jenitennison.com/
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list