RE: [xsl] XSLT vs Perl

Subject: RE: [xsl] XSLT vs Perl
From: David Tolpin <dvd@xxxxxxxxxxxxxx>
Date: Wed, 4 Feb 2004 01:48:20 +0400 (AMT)
>
> > I am just asking about advantages of use XSLT 2.0 over many 
> > similar tools.
>
> XSLT 1.0 is highly successful. It's the language of choice for people
> who want to do XML transformations. You say so yourself.
>
> Yet we all know on this list that XSLT 1.0 has severe limitations. It's
> very hard to do grouping, it's hard to do string manipulation, it's hard
> to handle dates.
>
> We've provided facilities in 2.0 that greatly ease these problems.

It is similar to how Algol 68 had been improved over Algol 60.

>
> Therefore, if people preferred XSLT 1.0 over other languages when
> performing these tasks, despite its shortcomings, they will certainly
> prefer XSLT 2.0 over other languages.
>
> Is that a good enough rationale for you? 

No, but not because I've made my mind up (although I am not sure
what these words mean, I am guessing from the context). The question
is not whether convenient string manipulation is necessary. It is.
I am all for easy grouping and convenient string manipulation. 

But string manipulation is not convenient in XSLT 2.0. It is as messy
as in perl, just without the rest of perl to compensate for the mess
(I am only mentioning perl because the working draft for XSLT 2.0 does).

Grouping is not easy with XSLT 1.0; but XSLT 2.0 makes it better for
a pre-selected subset of grouping tasks; and my grouping problems do
not always match the tools XSLT 2.0 provides; instead of keeping
the semantic simple and developing optimization and collaboration 
techniques, XSLT 2.0 forces the programmer to use algorithms hardwired in the
implementation.

Dates are a problem. It is an open question whether non-XML data should be
processed by XSLT or by another tool colaborating with XSLT; I admit there are
can be various approaches. But for me personally, it is not a question whether
handling dates should be ad hoc functionality fixed in the language. It should
not. If stemming of English words is not supported by XSLT, why parsing of
English dates does?

> P.S. Renaming functions because someone thinks of a better name is not what
> the game is about. It would be totally irresponsible to make incompatible
> changes on such a whim, and no-one would thank us for it - for everyone who
> liked the new name, there would be two who preferred the old name, and a
> hundred who don't care what it's called so long as it doesn't change. 

XSLT 2.0 is already not fully compatible with XSLT 1.0.  Renaming functions and
changing syntax for XPath predicates is just a small part of things that should
be done; the latter it happens, the worse; a mix of &lt;=, div, != not() is a
thing one can only live with keeping a reference card next to the keyboard.

And, most people do not care indeed what happens with XSLT 2.0, of those who
responded to my 'troll', few noticed that I am talking about the working draft,
not about the TR. Two clean languages with different syntax built upon the same
core are easier to learn and support and maintain than one big and inconsistent
one.

David Tolpin http://davidashen.net/


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


Current Thread