Re: Designs for XSLT functions (Was: Re: RE: syntax su

| > I think clearly separating the specification of the abilities:
| >
| >   -> to statically define and statically
| >      invoke functions in XSLT, and
| >
| >   -> to dynamically invoke functions
| >
| > would be useful. Some implementors may be interested in the former,
| > but not the latter, or vice versa.
| 
| I do seem to be having trouble with terminology on this topic. By
| dynamic invocation do you mean something like
| exsl:function()/exsl:call()?

By dynamic invocation, I mean any approach which ends up
evaluating runtime-provided strings to ultimately invoke
functions in an XPath expressions. Those functions could
be built-ins or user-defined functions, that shouldn't matter.
This is an orthogonal capability to the existence of
functions written in XSLT and the design of the latter
should not be entangled with the desire to have a
saxon:evaluate()-like function or some kind of 
dynamic-dispatch function invocation.

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.

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.

______________________________________________________________
Steve Muench, Lead XML Evangelist & Consulting Product Manager
BC4J & XSQL Servlet Development Teams, Oracle Rep to XSL WG
Author "Building Oracle XML Applications", O'Reilly
http://www.oreilly.com/catalog/orxmlapp/



 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list