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: Uche Ogbuji <uche dot ogbuji at fourthought dot com>
- Date: Tue, 20 Feb 2001 07:42:18 -0700
- Reply-To: xsl-list at lists dot mulberrytech dot com
> > > > I think clearly separating the specification of the abilities:
> > > >
> > > > -> to statically define and statically
> > > > invoke functions in XSLT, and
> > > >
> > > > -> to dynamically invoke functions
>
> I don't see any need for special syntax to invoke functions whose name is
> decided at run-time. That can easily be done using a general-purpose
> evaluate() extension that constructs XPath expressions from strings.
I do see the need.
First of all, exsl:call() would be more efficient than exsl:evaluate() in any
implementation scenario I can readily imagine. The former simply expands the
name and looks up in a symbol table. The latter involves full LR(k) parsing,
with lexing.
Also, there is the special ability Jeni and I have suggested for exsl:call to
permit named parameters, which I think is very useful.
--
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