Re: [xsl] RE: Designs for XSLT functions

[Uche Ogbuji <uche dot ogbuji at fourthought dot com>]

> > 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 
re-used?


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