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

["Kevin Jones" <kjouk@xxxxxxxxxxx>]

Jeni Tennison wrote:
>
>I see the route being:
>
>  user-defined extension functions (in XSLT or other languages) ->
>    community standardisation ->
>       W3C standardisation
>

I guess we differ here. It not clear to me that the first step is required
although XSLT based user-defined extensions would at least be portable if it
is. I don't think we have a strong enough case either way but it looks like
an expensive option to assume we do need user-defined functions.

>
>I also think that implementers will be more sympathetic to
>implementing a standard means of extending their implementations than
>to committing to constantly adding these functions themselves.  But I
>may well be wrong on that.

That's an interesting question. I wonder if it would make sense to try both
of these approaches simultaneously to see which is actually more successful
in practice.

>
>David Rosenborg also made a good point about the performance
>implications of *only* having standard extension functions - the more
>functions that you add to a language, the heavier-weight the
>implementations and the slower they get.  Allowing user-defined
>extension functions keeps it fairly clean and light.

Speaking for myself I can't see this problem. Normally these functions have
little to no impact other than increasing the code base. It would have the
effect of increasing the amount of work required to create a new processor
which may not be a good thing. If I implemented an extension function it is
going to perform at least as well as a user defined function and very likely
a lot better. This is simply because the implementer  have access to the
processor internals which normally allows them to implement a better
algorithms to solve the same problem.

>
>On the complexity front - certainly adding a couple of extra elements
>and adding the opportunity to define snippets of code in functions
>rather than in templates adds a little to the complexity of XSLT, but
>I don't think it adds a huge amount. Functions are just like named
>templates, really, they're just called in a different way. But I'm
>thinking about complexity for users here, but perhaps you're thinking
>for implementers?

I am rather implementer centric on these issues. I just see the number of
issues that are being raised by user defined extensions and equate that into
complexity. There appears to be a lot of overloading on existing semantics
with special rules everywhere. XSL is so full of exception cases at the
moment that I would like to see the language getting simpler not more
complex in any form.

>
>Just to make it clear - are you opposed only to XSLT as the extension
>language, or to any language?

Pretty much the use of user-defined extensions in any form. I see XSLT like
SQL, a language not designed to handle this issue. When I initially looked
at the problem XSLT defined extensions looked the obvious solution.
Following the recent discussions on the subject I just find it difficult to
see how this can be achieved in a way that really improves XLST, i.e.
elegantly with good performance and without additional complexity.

>
>Cheers,
>
>Jeni
>
>---
>Jeni Tennison
>http://www.jenitennison.com/
>

Regards,
Kev.


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list