This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: [exsl] Re: Draft 0.1 - call for comments (longish...)
- To: xsl-list at lists dot mulberrytech dot com
- Subject: Re: [xsl] [exsl] Re: Draft 0.1 - call for comments (longish...)
- From: Uche Ogbuji <uche dot ogbuji at fourthought dot com>
- Date: Thu, 01 Mar 2001 10:29:24 -0700
- Reply-To: xsl-list at lists dot mulberrytech dot com
> >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@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