This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: RE: Designs for XSLT functions
- To: xsl-list at lists dot mulberrytech dot com
- Subject: Re: [xsl] RE: Designs for XSLT functions
- From: Uche Ogbuji <uche dot ogbuji at FourThought dot com>
- Date: Tue, 20 Feb 2001 08:07:47 -0700
- cc: mhkay at iclway dot co dot uk
- Reply-To: xsl-list at lists dot mulberrytech dot com
> Michael Kay wrote:
>
> > Far too restrictive; it doesn't allow you to do any processing of node-sets
> > that can't be done by standard functions, for example it wouldn't allow you
> > to implement max() and min().
>
> Hmh, I think you missed my point about having a conditional
> construct in XPath.
[snip illegal XPath 1.0]
I think there is some confusion here.
My goal in this effort is to try to come up with a simple mechanism for
implementing XSLT-based extension functions in XSLT 1.0. This practice would
help guide the discussion of what should emerge in XSLT 1.1 and 2.0,
especially if enough implementors hop on board.
Mike Kay has already led the way with xsl:function, which is why it has been
the straw man. Jeni has (at least as I read it) kicked off a discussion of
how this can be generalized across implementations.
I think it's most useful to stay within the bounds of legal XSLT and XPath
1.0, especially since I think all we want has been demonstrated as possible
within those bounds. After establishing things a bit, we can work up an
informed wish-list of XSLT/XPath > 1.0 enhancements with respect to XSLT-based
extension functions.
--
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