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

[Uche Ogbuji <uche.ogbuji@xxxxxxxxxxxxxxx>]

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