Re: [xsl] RE: Designs for XSLT functions

Subject: Re: [xsl] RE: Designs for XSLT functions
From: Uche Ogbuji <uche.ogbuji@xxxxxxxxxxxxxxx>
Date: Tue, 20 Feb 2001 11:22:55 -0700
> > An apply() function (which simply calls another function whose
> > name is decided at runtime) would be easier to use than a
> > general-purpose evaluate() routine though.  Programmatically constructing
> a
> > syntactically valid XPath expression can be tricky.
> >
> > Apply() would likely also be easier to implement and more efficient
> > than evaluate().
> Ease of use? Programmers using ODBC or JDBC are very used to constructing
> SQL statements at run-time, and rarely complain.
> Ease of implementation? It's easier to implement one construct than two, and
> if one is a subset of the functionality of the other, I'd rather implement
> the more general one.

I agree, since ft:evaluate is a 2-line Python function, that implementing both 
is "more" difficult than implementing just the one.  But given that I expect 
exsl:call to be a 4-line Python function, I'm certainly not too worried.

But, of course, if it is an implementation inconvenience for you, that's 
certainly a large point against exsl:call().

> Efficiency? Show me the evidence! It's easy to use the same kind of tricks
> as one uses for format-number(), caching the format patterns that have been
> used in the past so they don't have to be parsed again.

But what if the usage patterns are such that the expressions are not so often 

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