Re: [xsl] [exsl] EXSLT 1.0 - Common, Sets and Math

Subject: Re: [xsl] [exsl] EXSLT 1.0 - Common, Sets and Math
From: Uche Ogbuji <uche.ogbuji@xxxxxxxxxxxxxxx>
Date: Sat, 10 Mar 2001 09:35:59 -0700
> David Carlisle wrote:
> > 
> > As for what functions to stick in exslt I'd have a policy of if in doubt
> > add it. So in particular I'd probably start by suggesting all the saxon
> > ones. (Thus including saxon:function) This just gives a namespace
> > that isn't saxon specific that means that other implementers can choose
> > to implement these functions if they wish. Similiarly of course they
> > could suggest further functions to be added.
> > 
> I'm pretty happy with Jeni's suggestions so far - and glad you agree
> with the idea of not postponing exsl:function till XSLT 2.0.
> I think proposing the whole saxon function set might prove a bit
> indigestible for non-saxon implementors,

Not this implementor.  Mike Kay has great ideas and a great user base.  
Chances are that most of his functions are very well-conceived.

> in terms of pride if nothing else.

Hmm.  This would be sort of like being too proud to implement XSLT because 
James Clark got there first with XT.  But then again there is no accounting 
for irrationality.  However, I think we should dispense with worry over this 
until we hear some clear opposition to Jeni's excellent function choices to 

> Let's use it as an excellent kick-off spot, but let the exsl list
> be a genuine community proposal.

I think we can have both, of course.  Start with Saxon, decide which ones to 
leave out and which others to add (I have my own list, of course).

> I like Jeni's approach of defining extra functions as extension
> functions, so basically anyone who's gone as far as impelementing
> exsl:function can (I'm waving my hands in the air a bit here) somehow
> incorporate the standard definitions and get them more or less for free,
> with the option of hand-coding any that they wanted to optimise.

Yes.  This is why implementing exsl:function is on my to-do list for today.  I 
expect it might be a bit trickier than implementing the others because I have 
to mind the many optimizations we've made in function dispatch.

Uche Ogbuji                               Principal Consultant
uche.ogbuji@xxxxxxxxxxxxxxx               +1 303 583 9900 x 101
Fourthought, Inc.                
4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA
Software-engineering, knowledge-management, XML, CORBA, Linux, Python

 XSL-List info and archive:

Current Thread