Re: Designs for XSLT functions (Was: Re: [xsl] RE: syntax sugar for call-template)

[Uche Ogbuji <uche.ogbuji@xxxxxxxxxxxxxxx>]

> > 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?
> 
> 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"

By making it a functional restriction rather than a structural restriction, I 
think we might head off any other gnarly gotchas that might come up.

Speaking of gnarly, I'm assuming xsl:call-template can be used within 
exsl:function.  If so, is it permissible for the exsl:result to be in the 
called template, or so on down the chain?

I'd say "scary thought: no", but how to best restrict this?  Structurally?  
("Every exsl:function must have an exsl:result within the nodes in its 
descendant axis").

Note that in the above I'm just exercising my bias towards "exsl:result" 
rather than "exsl:return".  Substitute your name of choice until we decide.


-- 
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