From: Wayne Steele <xmlmaster@h...> > 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.
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format