This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: [exsl] EXSLT 1.0 - Common, Sets and Math
- To: xsl-list at lists dot mulberrytech dot com
- Subject: Re: [xsl] [exsl] EXSLT 1.0 - Common, Sets and Math
- From: Uche Ogbuji <uche dot ogbuji at fourthought dot com>
- Date: Sat, 10 Mar 2001 09:30:50 -0700
- Reply-To: xsl-list at lists dot mulberrytech dot com
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@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