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: xsl-list at lists dot mulberrytech dot com
- Subject: Re: Designs for XSLT functions (Was: Re: [xsl] RE: syntax sugar for call-template)
- From: David dot Rosenborg at pantor dot com
- Date: Mon, 19 Feb 2001 19:25:11 +0100
- CC: mail at jenitennison dot com
- Reply-To: xsl-list at lists dot mulberrytech dot com
> Personally, I think that this is too restrictive. As you point out,
> it makes ifs and chooses quite difficult.
[ snip ]
> 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>
Yes, my proposal relies on a conditional construct in XPath. I
think it's more worthwile to try and get such a thing in as
early as possible than to try and figure out a intuitive
and concise definition of how the mix of XPath and
arbitrary template instructions should behave.
I think your example with xsl:for-each shows that this isn't
straight forward. You would have to recursively allow
and dissalow constructs for descendants of a xsl:function.
On the other hand I think my proposal would be very easy to define.
You could think of it as a parameterized global xsl:variable.
No special rules and exceptions, just straight forward XSLT as
we know it. Then again, it relies on a XPath conditional construct
to gain full flexibility.
Cheers
</David>
David Rosenborg
Pantor Engineering AB
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list