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: "Kevin Jones" <kjouk at yahoo dot co dot uk>
- Date: Thu, 1 Mar 2001 15:08:33 -0000
- Reply-To: xsl-list at lists dot mulberrytech dot com
>
>> However, following on from comments by Dimitre Novatchev I am finding it
>> hard to see the how user defined extension functions can be
>implemented in
>> XSLT without adding a considerable amount of complexity to a
>language which
>> is currently (1.0) simultaneously both very elegant and very confused
>> (confusing?).
>
>[thoughtful arguments snipped]
>
>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.
It feels to me a bit like trying to run before learning how to walk. Not
that having 'running' as your objective is a bad idea. Its clear that we can
easily, elegantly etc support a set of standard extensions but not that user
defined extension will be the same. I would of course be happy to be proved
wrong but I haven't seen anything in the recent discussions that makes me
change my mind about this.
Kev.
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list