Re: Designs for XSLT functions (Was: Re: [xsl] RE: syntax sugar for call-template)

Subject: Re: Designs for XSLT functions (Was: Re: [xsl] RE: syntax sugar for call-template)
From: Uche Ogbuji <uche.ogbuji@xxxxxxxxxxxxxxx>
Date: Tue, 20 Feb 2001 07:39:08 -0700
> I don't debate that both functionalities are useful,
> only that their design should be kept orthogonal and
> be described separately, because dynamic function invocation
> can work for built-in or user-written functions indepedent
> of the existence or not of user-written functions in XSLT.
> And conversely, user-written functions in XSLT could
> be supplied without a saxon:evaluate()-like functionality
> being their to invoke them dynamically.

I think what I'm missing is exactly what manner of additional distinction you 
are seeking.  We have suggested "my:func" and "exsl:call('my:func'), which 
represent static and dynamic dispatch respectively.  Doesn't this satisfy your 
concerns?  Of course there is no reason exsl:call() could not dispatch 

I consider exsl:evaluate() to be another matter altogether.  It's more than 
just function invocation, it's dynamic XPath parsing and evaluation.  
exsl:call(0 does no parsing besides q-name expansion.  It's basically just 
symbol-table look-up.

> Functions written in XSLT should be invokable in a way
> that is indistinguishable from any built-in function.
> I should not *have* to pass function names as strings
> and argument names as strings to invoke a function which
> has been statically declared.

Good.  This is one of the issues that Jeni brought up as design choices, and 
so far everyone I've seen respond agrees with you.

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