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: Uche Ogbuji <uche dot ogbuji at FourThought dot com>
- Date: Tue, 20 Feb 2001 13:18:12 -0700
- Reply-To: xsl-list at lists dot mulberrytech dot com
> > 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").
>
> There's a good point there about what to do if no exsl:result element
> is instantiated. Returning an empty node set would at least stop
> function calls from breaking if the result of the function was used as
> a node set. Or should it be an unrecoverable error if no exsl:result
> is instantiated?
I don't mind saxon:functions's answer to this: the result is an empty string
in the absence of exsl:result
--
Uche Ogbuji Principal Consultant
uche.ogbuji@fourthought.com +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