[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

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

Subject: Re: [exsl] Re: Draft 0.1 - call for comments (longish...)
From: Jeni Tennison <mail@xxxxxxxxxxxxxxxx>
Date: Mon, 26 Feb 2001 09:20:17 +0000
adding function in xslt
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


Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.