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

[Jeni Tennison <mail@xxxxxxxxxxxxxxxx>]

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