Re: RE: Designs for XSLT functions

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