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