This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: [exsl] Re: Draft 0.1 - call for comments (longish...)
- To: "Kevin Jones" <kjouk at yahoo dot co dot uk>
- Subject: Re: [xsl] [exsl] Re: Draft 0.1 - call for comments (longish...)
- From: Jeni Tennison <mail at jenitennison dot com>
- Date: Mon, 26 Feb 2001 09:20:17 +0000
- CC: xsl-list at lists dot mulberrytech dot com
- Organization: Jeni Tennison Consulting Ltd
- References: <ELELJKIDBHJGKEMFLAFKMEFECNAA.kjouk@yahoo.co.uk>
- Reply-To: xsl-list at lists dot mulberrytech dot com
Hi Kevin,
> I am sure I speak for everybody on this list in thanking Jeni for
> the effort and skill she has demonstrated in putting together this
> document and facilitating the preceding discussions. Thanks so much.
Thanks :) And thanks for the very interesting points you make in your
email. I agree that we have to come up with a persuasive rationale for
having user-defined extension functions in XSLT - if there isn't one,
then there's no point in doing it. I've addressed some of your
comments below.
> Instead of standardizing on a way to write extension functions
> define a set of functions that can be used to solve most common
> issues. This can be published as a community standard so pressure
> can be added to vendors to conform or die! The Saxon extension
> functions would be a good starting point. This could be seen as a
> proactive force on the next XSLT/XPath standards to improve
> community feedback. Currently something the W3C *appears* to perform
> badly due to its closed standards process. This may not give the
> immediate gratification of being able to just write your own
> extensions but I think it would do a lot to keep down the complexity
> and increase the portability and maintainability of XSLT.
I would definitely like to see common functions supported internally
by XSLT processors, and to have a community-led initiative to develop
those standards. So I think we have the same goal, I just view this
step of allowing user-defined extension functions as being part of the
route to it.
I see the route being:
user-defined extension functions (in XSLT or other languages) ->
community standardisation ->
W3C standardisation
In other words I think that the definition of extension functions by
users will help the community to see what functions are useful and
give a good starting point for their standardisation. If anything, I
think that user-defined extension functions will lead to quicker
adoption and more robust definition of those standards.
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.
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.
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 don't understand how adding a standard way of defining extensions
functions diminishes the portability of a stylesheet? I think that
there will be a lot more portability issues when it comes to adding
community standard functions - some processors will have some, some
others. In the picture of the future in my head, all implementations
support user-defined extension functions in XSLT, authors always
implement a function in XSLT, and no matter whether the function has
built-in support in the processor or implementation in another
extension language, the XSLT implementation is always there as a final
fallback.
> I think that writing extension functions in XSLT appears initially
> very attractive (as apposed to Java, etc) but in the bigger scheme
> of things it appears to me to be a short term hack that will
> significantly add to the complexity of XSLT without improving the
> language.
Just to make it clear - are you opposed only to XSLT as the extension
language, or to any language?
> I am assuming that it is self evident that having implementations
> provide a set of commonly needed extension functions is far
> preferable than everybody writing a version for themselves.
I don't think that everyone should be writing versions for themselves
- as Mike suggested, there could/should be a central repository for
user-defined extension functions, in a range of languages, where there
are commonalities. It's that repository that will highlight the
much-used extensions.
As I've argued above, it's not clear that it is preferable to have
everything built in to the implementation - having too much built in
makes the implementations larger and slower, and increases the
portability problems of having different functions supported by
different implementations.
Cheers,
Jeni
---
Jeni Tennison
http://www.jenitennison.com/
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list