Comments on: What happened to XSLT?

By: Steve

Steve — Tue, 06 Oct 2009 01:21:21 +0000

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!

By: Ivan Pepelnjak

Ivan Pepelnjak — Tue, 17 Mar 2009 17:20:58 +0000

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.

By: Daniel Lemire

Daniel Lemire — Tue, 17 Mar 2009 13:09:50 +0000

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.

By: Samuel Jack

Samuel Jack — Mon, 16 Mar 2009 19:21:30 +0000

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#.