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

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

> 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 
built-ins.

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