Re: Designs for XSLT functions (Was: Re: RE: syntax su
> 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@xxxxxxxxxxxxxxx +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
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format