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: "Clark C. Evans" <cce at clarkevans dot com>
- Date: Tue, 20 Feb 2001 12:42:00 -0500 (EST)
- Reply-To: xsl-list at lists dot mulberrytech dot com
> > > 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?
> >
> > Saxon allows xsl:for-each with saxon:function, but doesn't allow
> > saxon:return within xsl:for-each.
>
> I'd generalize this restriction to say
>
> "It is an error for more than one exsl:result to be instantiated within the
> body of an exsl:function"
Is it true that "exsl:return" largely emerged since there was
no way to return a specific node as part of a result fragment?
I was wondering, what about <exsl:reference-of select="node-set" />
It does introduce a "node reference" data type (perhaps simulated
as a string). I guess this doesn't make it 1.0 compatible, however,
would this allow "exsl:return" to go away?
Clark
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list