Around 2000, some people believed that nearly all programming would be a matter of transporting and transforming XML. XML would be the universal data format, and all software would be a matter of transforming XML. If that were the case, then it would be very handy to use a language designed especially for transforming XML. That language was XSLT.
I’m sure some programmers write XSLT on a daily basis, and there’s probably a large amount of machine-generated XSLT out there. But it’s safe to say XSLT never became extremely popular. Maybe because the syntax is awkward. Not many developers like to write lots of angle brackets. Or maybe the declarative/functional style of the language isn’t as comfortable as a more imperative style of programming for most developers. I don’t really know. I thought XSLT sounded like a good idea, but I never learned it. My experience with XSLT consists of a few dozen lines I wrote six or seven years ago.
Along these lines, I ran across the following picture in a blog post entitled A picture is worth a thousand words: is XML dying? containing the following photo:
When I was planning my Master’s dissertation, one lecturer suggested the possibility of implementing a Turing Machine interpreter using XSL Transforms! I was pretty keen on XSL at the time, but I’m glad I didn’t take him up on it.
I remember reading back then that XSLT is a functional language and not understanding what that meant: in retrospect I’m glad I didn’t or I might have been accidentally put off functional programming for life!
I’m in the middle of implementing a Content Management System that makes heavy use of XML and XSLT, and I have to say, programming XSLT feels like swimming in treacle compared to working in something like C#.
As someone who has been teaching XSLT for 5 years now, I have to disagree. Granted XSLT is a niche programming language, but for what it does, it is really hard to beat. Want to turn an XML output into an HTML table? XSLT is the right tool for this job. You’ll have 5 lines of highly maintanable XSLT. It will be clean and the output will behave nicely.
And I don’t care if you dismiss XSLT, but you can’t dismiss XPath. What are you going to replace XPath with? And once you have learned XPath well, learning XSLT is not so hard.
What are you comparing XSLT with? With a particular language (C#) that copes with XML in a particularly convenient way? Fine. If you are already using C#, adding XSLT on top of your project won’t help. But not everyone will use C#. And it is not always a good idea to use C#.
There are many, many web sites that are XSLT driven. The database outputs XML, it gets transformed into HTML by some server-side XSLT. You just never see it. But it works and it works well. Tackling C# on top of it would make things for more difficult to maintain.
There is one alternative that was supposed to replace XSLT for many tasks, XQuery. Well. See my post on this subject:
Native XML databases: have they taken the world over yet?
http://www.daniel-lemire.com/blog/archives/2008/12/04/native-xml-databases-have-they-taken-the-world-over-yet/
So, XQuery has problems of its own.
XSLT has two huge problems: XSLT 1.0 (which lacks so many features that it makes you cry every time you’re trying to do something a little more complex) and lack of support for XSLT 2.0.
Most of my web sites use XML on the server and client-side XSLT transformations (whenever possible). It’s a great architecture, has fantastic response times in markup-reach pages (remember: you’re only transferring the actual data in XML), but sometimes it’s a nightmare to program.
Would I use something different today? Probably not, the idea is still fantastic. Would I prefer XSLT 2.0? Absolutely.
We use XSLT on a daily basis for our high end embedded products.
In lay terms what XML + Schema + XSL allows us to do is generate source code and data files (generally xml).
.. And this is the cool bit..
The target system can treat *these* data files as having been already validated (via a schema).
There is no need to put on belts-and-braces when accessing these files (way less source code + way more readable).
They are in essence part of the deployed application, but live on the filing system!