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

[Uche Ogbuji <uche.ogbuji@xxxxxxxxxxxxxxx>]

Wretchedly trying to catch up after my trips.

> David C. 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.
> 
> Hmm... I guess that with that approach you wouldn't mandate that a
> processor had to support all the functions (in a particular module),
> but leave it up to the author to check whether each function was
> supported?

I don't like this one bit.  I think modules should be implemented 
all-or-nothing.  Probably we should try to arrange the module so that they 
would probably involve similar implementation techniques.

The one bit of trouble I could see that causing is a split of sets into one 
section that allows dynamic programming (the set/string parameters functions ) 
and another that doesn't (the set/set parameter functions).  But I'd want to 
hear from implementors that this dynamic programming is a problem in this case 
anyway.  Andrew has mentioned that it's a problem in the general case, but 
maybe this incidence is limited enough.

But I do think that if EXSLT picks up steam among implementers that we should 
strongly encourage adoption by entire modules.

> That sounds reasonable to me - it means that 'EXSLT conformant
> processors' doesn't mean anything, but it means that implementers can
> implement what they choose. (I was aiming for a middle ground where you
> could have a processor that was conformant to a *part* of EXSLT, and
> the modules were small enough for implementers to consider
> implementing.)

I think you came pretty close.  In implementing them, I was able to use a lot 
of cut-and-paste between function implementations in each module.


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