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

Subject: [xsl] [exsl] Re: Draft 0.1 - call for comments (longish...)
From: "Kevin Jones" <kjouk@xxxxxxxxxxx>
Date: Sun, 25 Feb 2001 15:07:54 -0000
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.

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?).

One of the strengths I see in the XSL model is that procedural business
logic programming is banished to XML generation code far away from
presentational and transformational work. Introducing complex procedural
programming through the backdoor would in my opinion be a mistake. There are
many general-purpose languages much better suited for this work. On the
other hand, the restrictions placed on XSLT writers in the current standard
means that finding solutions (quite often obscure) to common transformation
problems has become the overriding activity of this list. The W3C model of
making it easier to write non-portable extensions appears to me as a short
term patch that will create as many problems as it solves.

If the goal is to ease the difficulties faced by in the every day use of
XSLT via extending the power of XPath (in this case via XSLT based XPath
functions) I can think of two alternatives ways of thinking about the
problem.

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.

It is not completely clear that a standard set of extension functions would
cover most currently difficult transform cases. Working this out would be a
useful exercise in trying to decide if user defined extensions functions
really are going to add value. I am assuming not, as so many problems on the
list appear to be common.

If, as reported, XPath is going to become part of the DOM model in the,
drawing on the parallel between DOMs and databases, it begs the question of
how this problem is solved in the DBMS community. The logical equivalent of
an extension function is a stored procedure. Here you are often given access
to the underlying data structures (via cursors) to create whatever function
you want. In a similar model for XSLT processing it would be the DOM
provider who would define how to create extension functions (probably your
DOMs native language equivalent of plug-in modules). It's interesting to
point out that stored procedures have there own language and environment (I
believe primarily because of the efficiency issues). XSLT like SQL appears
to me to be simply not suited to creating user defined functions. This model
would then be more of the DOM Extension API something like the Java JNI.

In summary I could quite easily back a standard set of extension functions
without any issues. I think long term we will see implementation of DOM
based extension API's based around some standards. Preferably both models
could be used so that common solutions don't have to be implemented by hand
while you also get the ability to write your own extensions for those really
tricky cases.

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. 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 am not really saying that the proposal won't work as laid out. More that I
don't think user-defined functions in XSLT are a good idea at all. I
understand the current restrictions in XSLT that you could solve with
user-defined functions but think better solutions to these restrictions are
to be found elsewhere.

Either way the use of this list to promote what the XSLT community really
needs has got to be one of the most important steps taken is recent months
on XSLT.

Kev.
(An implementer and user of XSLT)


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


Current Thread