This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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




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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]