xml-dev - Re: transformations

[Paul Tchistopolskii <paul@qub.com>]

From: Wayne Steele <xmlmaster@hotmail.com>


> Hey Paul, Tell us what you really think!

I can tell, but then you have to kill me. As usual.

> 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 agree with this. This is a statement which could be applied 
to any existing tool in the world, so it is easy for me to agree 
on this statement about XSLT.
 
> But I really like the processing model of XSLT 

So did I.

My point is that:  

1.  I like processing model of XSLT but 
2.  I know there are some cases when another processing model is 
better than current processing model of XSLT and this is orthogonal 
to RAM issues, syntax issues  e t.c. 

> and I'm hopeful about all 
> three of these problems:

Nope. There are more than three, but some are obvious and 
understandable and some other are not so simple.

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

Do you think compiled stylesheets have something to do with RAM ?
Nope. It does not matter how fast is the stylesheet, when JVM starts swapping  
like a dog. There are other efforts trying to address RAM issue. All of them 
are in alpha. How long it will take them to get to 'beta'? 

For example, Netscape 6.* was in alpha for a couple of years ( and still 
is in alpha, no matter they call it 'release' )

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

No, I don't want XSLT-Lint. I want XSLT-C++ that killed any need in Lint.
C++ is not exactly what I want, but it is close, actually.

Of course designing C++ for doing simple things is not reasonable.

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

Schematron? I doubt. As usual, this all could be done to some degree 
with a lot of coding. But there is no point in such a  framework if 
the language itself supports some things. 

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

This is not actually a big deal that IE 5 MS XSL was not XSL. 
The problem is that W3C is silent about the future of XSL.

When W3C is silent - big companies play their game
( like MS did with their MS XSL ) I don't like the way big 
companies play their game.  

... uh ... I've said that ... now I will go to hell ....
 
> 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'.

Consider it 'we-have-legacy' excuse. And please  - tell it loudly  that W3C
will not bother with XSLT as a server-side XML transformation language. 
And then watch the progress ( instead of watching bullshit and politics ).  
 
> 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.

Sorry. I doubt this will be the future. XML Query WG does great, but I hardly 
understand how they'l plug some pieces together. XSLT has better 
chances to mutate into universal transformation language. If, of course, 
W3C cares about such a language ( which is questionable ).

I really hate guessing. This guessing has no point ! Nobody can guess 
what will happen on  XSL WG and what will be the changes. I'm not 
making bets on W3C - they're unpredictable.

My conclusion is :

<advice for="newcomer">

XSLT ? Server side? 

Use on your own risk and do that until you are fluent in 
XSLT / XML ( schedule 6 months for this of hire the expert ) 

When gaining the experience  - be prepared to redesign 
everything at any moment of time.  

After / if you get tired of this - there is a big probability that 
there will be XSLT 2.0 or at least understanding what will 
be XSLT 2.0

And yes - you'l have a big fun with XSLT and some day you 
may think that it is the silver bullet. But then you may change 
your point of view. Like many others did.

</advice>

Rgds.Paul.

PS. Sorry to tell it, but I think that Leventhal was correct long time ago
sayng that XSL should not be under W3C umbrella.  I really like  
XSLT,  I really like XSL, but making this beast into W3C standard 
was a big, big, big mistake because of obstacles this caused to 
the entire process. 

I've changed my position on this issue, because when Leventhal
was writing those things ( in this list ) I was against his view. 

Now I see that he was right and I was wrong.  You should not 
make every good beast a standard, because not only it promotes 
that beast, but it also kills everything around. And that killing 
is not always good thing.

PPS. Please, those who are saying that "calling something W3C
standard does not kill anything" - could we be honest?  It does. 
Managers and other people with money are not reading XML-dev 
list, they are reading magazines.