[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: [exsl] Re: Draft 0.1 - call for comments (longish.

Subject: Re: [exsl] Re: Draft 0.1 - call for comments (longish...)
From: Uche Ogbuji <uche.ogbuji@xxxxxxxxxxxxxxx>
Date: Thu, 01 Mar 2001 10:29:24 -0700
Re:  [exsl] Re: Draft 0.1 - call for comments (longish.
> >I agree that defining extension functions in XSLT might be a performance
> >problem, although I disagree with you that it mars any of the
> >elegance of XSLT
> >itself.
> >
> >At any rate, I expect that implementers can provide the best of
> >both worlds
> >you outline.  They can look up exsl functions invocations first in their
> >native libraries, and if not found, then they look for the
> >corresponding exsl
> >implementations in XSLT.
> >
> >This would provide a great measure of the transparency that some
> >of us prefer,
> >and the cross-implementation compatibility that the XSL WG seems to be
> >striving for.
> 
> I agree that dual implementation would get around any performance problem
> but my reading of EXSL certainly leads me to think this was not currently
> planned. Perhaps I have missed something here? I see it as more important to
> provide a standard set of extension functions than implement a model for
> user-defined function at this point.

I heartily agree and I don't want my interest in the XSLT implementation of 
extension functions to mask the fact that my *primary* interest in the 
xsl:script-triggered discussion is the establishment of standardized libraries 
of extension functions.

To me the exsl:function effort is a handy bootstrap for implementors.  Say 
that we agree that exsl:distinct, exsl:intersection and exsl:union all be part 
of the standardized library.  All an implementor has to do is implement 
exsl:function and then cut-and-paste Jeni's nice library from her document, 
and they're in.  Now they can start implementing each function natively for 
better performance at their convenience (and that of their users).

The other argument for exsl:function is that it makes it easier for users to 
roll their own specialized functions which don't happen to make any community 
standards.


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


Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.