[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Application Design
>[Don Park] >I agree with everyone that XSLT is the right tool for manipulating XML There are many applications for which, XSLT is *not* the right tool for manipulating XML. The XSL spec. itself points out that XSLT is not intended to be a general purpose XML to XML transformation tool:- "XSLT is not intended as a completely general-purpose XML transformation language. Rather it is designed primarily for the kinds of transformations that are needed when XSLT is used as part of XSL." http://www.w3.org/TR/xslt James Clark himself has been known to post to this list about the application areas where XSL is probably not the right way to go: "XSLT is better at down translations that up translations; if your transformation is going from a less-structured form to a more-structured form, XSLT may not be a good choice" http://www.biglist.com/lists/xsl-list/archives/199908/msg00210.html Also "XSLT is better at transformations on structure than transformations on content; if your transformation is doing complex transformations on the text content of the document, XSLT may not be a good choice" Unless the work I do with XML (both internally and consulting with some thumpingly big international corporations) is very unrepresentative, the limits of XSLT hit hard and very fast in the development cycle. Most non-textbook XML transformations I am involved with require either a) PCDATA based manipulations and b) external integration e.g. dbms, web services etc. Insofar as they are possible with XSLT they are complex and read-only at best. In many cases they are just not possible at all. I repeat my assertion made in an earlier post that the irrational exhuberance about XSLT will be the cause of wholesale server-side re-writes of XML transformation systems in the medium term. In the short term, users will try to overcome XSLTs limitations with fancy debuggers and fancy developers tools. The vendors are already rubbing their hands with glee at the prospect! Remember what happened to C++ - it got so complex that the majority of programmers (on Windows anyway) ended up with visual tools. These tools in no way allowed you to visualize what C++ was. They purely acted as buffer zones between the programmer and the complexity of the language. Over time, the vendors developed a stranglehold and effectively forced organizations using C++ to purchase visual tools and then specifically to look for visual programmers. The underlying C++ may have been standardized but the surrounding tools were proprietary and involved $$$. To the detriment of the idea that C++ was an open "standard". XSLT is heading in the same direction it seems to me. To the detriment of the idea that XSL is an open "standard". Summary: XSLT has its uses but it is surprisingly useless in some common server-side scenarios. XSLT gets complicated quickly. The side-effect free nature of its processing model causes much pain for developers. The theoretical reason for this - parallelization of execution of the stylesheet - seems to me to be unjustified. It puts too much complexity on the programmers plate for what is after all an optimisation feature. Arguments against the "just use XSLT" mantra, including this one, will be pooh poohed by vendors who know full well what the limitations are but see lots of $$$ in debuggers, visual tools, consulting etc. etc. regards, Sean
|
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
|