|
An interesting post and a good read, although I think it is useful to point out that the main proponents for XSLT posting to this board have written books on the technology, so I consider it in their vested interest to promote it (although obviously both posters saw some value in XSLT prior to writing the books).
I think one thing that is generally overlooked in such debates is the general trends of technology adoption in IT. People are still integrating interpreted/memory-managed languages (Java/Perl/Python) into their codebases. Many shops are trying modelling tools for the first time. Some shops are still migrating to relational databases.
Adoption of XML technologies in most shops is probably limited to pilot projects for document interchange needs. XML is good for this, but I would be surprised if XML adoption ever gets past this level. I have not heard one compelling argument why an XML transformation must itself be an XML document. True, you can reuse parts of your original XML parser to process the tree transformation, but then is this engine better suited for this task than mature VMs and compilers?
Although XSLT allows you to separate document transforms from the rest of your business logic, is it ever really the case that real world apps decompose functionality that well? If a document transform is part of a larger function, why not just complete all tasks related to the function (arithmetic, database access, network access, for example) instead of breaking part of it out into a new syntax?
Added to which, does the functionality of XSLT approach the data manipulation facillities of traditional languages? And by this I mean can similar functionality be expressed in comparable levels of verbosity? Every XSLT example I have looked it is utterly verbose compared to what could be cranked out in Perl.
Brad
|
Previous Message
Up
