xsl-list
[Top] [All Lists]

RE: XSLT vs Perl

2004-02-03 10:35:09
Michael,

I did not say that XSLT 2.0 is bad. I had just asked, what is the
advantage in use of XSLT 2.0 over Perl or Python or Ruby. If this
is being done for the sake of diversity of scripting languages,
then I understand and accept it, though I would regret the original
idea of XSLT is lost. (The same is true in respect to perl, by the
way, except that I don't even regret).

Which specific facilities do you consider to be too difficult to learn
and use? Which things would you have left out, or designed differently?
Asserting that you could do a better job yourself in half the time is
all very well, but you need to demonstrate how.


I never asserted that I would do it better, nor that I would do it
better in half the time. Because I don't yet understand what is 'it'.

I did understand 'it' about XLST 1.0; it was XML manipulation language,
many compromises were worth them for the sake of sharpness and compactness.
I new the exact domain of XSLT, and I pre- and post-processed the data
to leave to XSLT only the part which it does in the best way.

I find it difficult to use the type system, as it is brought
in from XML Schema. I believe that it is non-orthogonal and overcomplicated;
and that a simpler type system, if any, would be much more convenient.

I find it difficult to use regular expressions without language tools
to structure and combine them. I have the same concern about XML Schema
regular expressions and tried to sketch better syntactic ways at least
to prototype them. 

In my opinion, validation of constructed elements is not a good thing
because it does not serve to construct the result of transformation, but
only to mark the result as valid or not; validation can be performed
at subsequent processing steps without any loss in expressive power.
 
There are other numerous concerns.

I need time to name and explain them. I do not believe my explanation
will affect development of XSLT specification, whether it is good or bad;
that is why I am in fact not asking why XSLT 2.0 is pretty or ugly.

I am just asking about advantages of use XSLT 2.0 over many similar tools.

At the same time, there were real directions in which XSLT 1.0 could have
been improved. In particular, I (still) see a need to clean up XPath and XSLT
functions, I had already asked this question before, but why current() is a 
node, but last() is a number? What does 'generate-id()' generate?

Another example is 'hints', such as keys; since their need is proved by time,
they could have been extended to indexing by position, making it explicit.

Yet another thing I had been saying about is computational complexity: there
should be a specification companion stating that time to add a node to a 
nodeset should not be more than linear with the size of the nodeset. Many 
similar
cases are more important than functions.

XSLT 1.0 did have a good chance to become a language that could be used
without paying a lot of attention to optimization of algorithms (expressed
in XSLT). In the same way as a normal perl/sed/awk programmer is normally
not concerned about performance of his regular expressions (unless he uses
GNU sed). XSLT could be kept small and simple if its consistency and 
theoretical base were improved.

Instead, lots of ad hoc features are being added.  

Do remember that a language specification is not designed as a tutorial.

I think I can read language specifications, I had read many.

It can be my fault, but I don't see what can be made easier or 
at least with comparable easiness using XSLT 2.0 than with 
any of other well-developed scripting languages currently 
widely deployed.

If you find DOM-level navigational programming easy, then you're welcome
to it.

I do not understand how this phrase is relevant to the subject. Where
did I propose DOM-level navigational programming as an alternative to XSLT?

David Tolpin
http://davidashen.net/

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



<Prev in Thread] Current Thread [Next in Thread>