This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: RE: Designs for XSLT functions
- To: xsl-list at lists dot mulberrytech dot com
- Subject: Re: [xsl] RE: Designs for XSLT functions
- From: Jeni Tennison <mail at jenitennison dot com>
- Date: Tue, 20 Feb 2001 17:31:44 +0000
- Organization: Jeni Tennison Consulting Ltd
- References: <002201c09b5b$85a842e0$fa363c3e@oemcomputer>
- Reply-To: xsl-list at lists dot mulberrytech dot com
Mike Kay wrote:
>> 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().
[snip]
> 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 think the important part to me here is "if one is a subset of the
functionality of the other". Unless we find a way of passing
parameters by name with static function calls, then evaluate() will be
limited to only passing values by position just as the static function
calls are. With a separate function (apply() or exsl:call or x:fn or
whatever you want to call it), we could have additional functionality
that included passing parameters by name.
Cheers,
Jeni
---
Jeni Tennison
http://www.jenitennison.com/
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list