xml-dev - Re: transformations

[Wayne Steele <xmlmaster@hotmail.com>]

Hey Paul, Tell us what you really think!

It seems that a concensus is forming on this list:
    1. XSLT works very well for some tasks
    2. XSLT is terrible for many common transformation tasks

I'm sensing some bitterness from you about actually writing XSLT.
I too have been burned by (a) slow processing time, (b) no decent error 
checking, and (c) Microsoft's non-standard implementation.

But I really like the processing model of XSLT and I'm hopeful about all 
three of these problems:

   A. Slow processing time
      I have seen several implementations (MS, and I think Sun) of 
'compiled' stylesheets. This should be a big performance improvement, and 
should keep improving.

   B. No Decent Error processing.
      I remember c used to have the same problem. This is just a sign of the 
immaturity of the language. You've got XSLT processors, right? Now you want 
XSLT-Lint?
      This can be solved through better authoring environments (IDEs, or 
Pre-Processing Macros) and stylesheet validation tools. I think schematron 
would be a good choice for an "XSLT-Lint" application (apologies if that 
term is already in use).

   C. Microsoft's Non-Standard Implementation
      MSXML 3.0 looks to have pretty complete XSLT and XPath 
implementations. Non-Standard extensions have been pushed into the ghettos 
specified in the XSLT Rec. While this has been (and still is) a headache, I 
think they're to be commended for a smooth migration to the standard, 
following through on the promises they made from the get-go
(Disclaimer: I used to work with this team at Microsoft).

People who push XSLT to the limits I think know they're "using a wrench to 
pound a nail". But it does get the nail in, right? Who wants to learn (or 
invent, in this case) a whole new tool, when they can make the one they have 
work? Consider it a form of 'code-reuse'.

I suspect the end-all be-all generalized XML transformation solution is to 
be the forthcoming language from the XML Query WG. This would explain how 
long it's taking them to release a language - it's a hard, diverse problem, 
and they want to get it right. But I betcha (hope) they've benefitted from 
all of the XSLT implementation experience. And I'm sure XSLT will always 
have a place for the things it does really well.


-Wayne Steele


>From: Paul Tchistopolskii <paul@qub.com>
>
>I think this should be written explictly, because I found that almost
>any developer who starts with XSLT usually  forgets about the
>hidden cost of using XSLT for transformations. The hidden cost is RAM.

   [snip]

>In more general case. When trying to use XSLT for aggregation
>of some small document,  constructing that small document out of
>many big documents ( not the way XSLT was supposed to be used,
>I think ) - you may agian find that because of this bult-in all-in-memory
>pattern  XSLT simply can not cope with some of usecases.

   [snip]

>I can provide other particular cases when XSLT 'fails'. Anything sensitive
>to mistyping of one letter is the case, for example. XSLT is in fact 
>'write-only'
>language with almost no guards against mistypings. Mistype one letter
>in any Xpath ( like it is "in any perl regular expression" ) - and pray 
>that you'l
>capture this error before it goes to production (if it resides in not 
>obvious
>branch of the processing). And now imagine somebody modifying the code
>written by other person and mistyping the letter, or  ... sorry ... 
>nevemind...
>
>We'l all see it soon, when XSLT will hit the market and armies of 
>developers
>will start writing tons of XSLT code ( not the case at the moment ).
>
>You'l not be given any warning ( and that's *impossible* to give that 
>warning
>without schema. When ( if ) they'l bring schema into XSLT I'l start 
>laughing and
>crying. I think nobody will ever use the resulting mix. That's why I've 
>started
>writing my own mix (xml-linux).  Only  because I don't expect somebody
>will do this for me. I'm currently tired of debugging XSL. Some days
>ago I got tired typing XSL - and that gave XSLScript which increased my
>XSLT productivity by the factor of 3.
>
>This is why I say that XSLT is perl. XSLT is very close to ( curent ;-)
>perl in style and advantages / disadvantages they both provide.
>
>It is easy to write something in XSLT ( well, it took me 2 years to
>become really fluent in XSLT, so maybe it is not 'that' easy ).
>But it is hard to support complex code written in XSLT, because
>it lacks 'real' modularity, 'real' inheritance and some other things
>invented by some not so stupid persons for writing complex layered
>processing code ( AKA 'transformations' ).
>
>Hey, long years ago XSL was for rendering nice pages on web-client.
>XSLT was a part of XSL and it is good for that domain.
>
>Why should it be good for *any* transformation?
>
>How it *could* be good? It was not designed to be good for any
>transformation.
>
>Belive me, reasonable change of  XSLT processing model, syntax
>and some other things is possible ;-)
>
>XSLT processing model is really bright ( I'l say 'brilliant' ) step,
>but to me XSLT always was the first step, not the last one.

   [snip]

>This again means they'r using XSLT not for what  XSLT
>was designed !  To query repositories, we have XQL , not XSLT !
>
>I'm scared by the message which is sent by XSLT. It is *so* fuzzy.
>BTW -  take into account that MS XSL  is not XSL and many
>people  still think that this obsolete dialect implemented by
>'default' distribution of MS IE has something to do with 'real'
>XSL.

   [ending snipped]

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at 
http://profiles.msn.com.