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

Subject: RE: [xsl] [exsl] Re: Draft 0.1 - call for comments (longish...)
From: "Kevin Jones" <kjouk@xxxxxxxxxxx>
Date: Thu, 1 Mar 2001 15:08:33 -0000

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


 XSL-List info and archive:

Current Thread