An Architect's View

CFML, Clojure, Software Design, Frameworks and more...

An Architect's View

XSLT Too Hard?

September 22, 2003 ·

A while back, Tim Bray wrote about XML being too hard for programmers. Not everyone agreed with him but there were some interesting comments in his original post.
Now Martin Fowler has effectively written that XSLT is too hard. Hopefully, this is a much less contentious position than Bray's because, if you ask me, XSLT isn't just hard, it's downright impenetrable! One of my team is our resident XML / XSLT expert and he can make XSLT do amazing things but it really does have a horrible syntax and, as Fowler says, some things are nigh-impossible to program purely in XSLT.
Fowler thinks scripting languages may help us here. He's using Ruby (which I'm not familiar with) to good effect. Whenever I need to work with XML, I jump into ColdFusion because it has good XML support and it's easy to work with.
What do people think - is XSLT viable or do you also jump into a scripting language of some sort when you need to manipulate XML?

Tags: programming

13 responses

  • 1 John Farrar // Sep 8, 2004 at 5:04 PM

    The cool tools that help generate XSLT are all targeted at converting a XML doc to HTML. XSL has other uses, and they don't seem to be getting the picture! Not only is it cryptic... better description than "hard". It is also that the tools generators don't seem to know how to use it for anything but HTML. It can still be said, most people just don't know what to use XML for in general... XSL... they are next to clueless!
  • 2 Bryan F. Hogan // Sep 8, 2004 at 5:04 PM

    There are a few things like splits and such that I would like to see added to the XSLT specification. I don't think XSLT is hard to use, cryptic or not understandable. I don't use the tools that generate XSLT, notepad is my only tool for this, so maybe the tools are what is making it hard for people to use.
  • 3 Jesse Ezell // Sep 8, 2004 at 5:04 PM

    XSLT is a lot like regular expressions syntax, it is just really hard to get your hands around. Now, Microsoft is supposed to be working on this X# project, that might make working with / transforming XML a bit easier, but until then, XSLT is the best XML based transformation language that we have. Generally, you have a choice between databinding, xslt, and writing some custom functions. Each has its own use. In my experience, their usefulness probably comes out like:<br /><br />1. DataBinding<br />2. Custom Logic<br />3. XSLT<br /><br />But, just because XSLT is last on the list doesn't mean that it is always the last choice. While DataBinding is great for a list of relatively similar items. XSLT is really great for transforms on entire xml documents. Also, having the ability to drop a custom XSLT file in an app to completely remodel the display of some data elements can be very useful (simliar to the use of CSS in HTML). It works ok for raw data, but databining to a grid or report usually works better for raw DB output, because you can add editing support a lot easier with databinding than XSLT (at least currently, but it would be very cool to be able to use XSLT for editable data too, not just read-only data...). Custom stuff works for those rare exceptions where you need some really funky display (maybe an editable tree view or something).
  • 4 PC Wroble // Sep 8, 2004 at 5:04 PM

    XML manipulation is what sold me on CF. I'm a long time ASP coder since ASP first came out. I went to ASP.NET when it came out and have a love/hate relationship with it. I was doing a project that needed some xml interaction/transformation to interact with a legacy DB between multiple servers. I looked at XSLT and said "no thanks". I then worked on it with .NET and SOAP and found it somewhat complex. I then looked into CF as MX was in beta. It was the perfect solution. Using a combination of cfhttp, cffile and cfxml i was able to move data between servers, write, change, delete xml files with just a few lines of simple code. I was hooked and fell in love with cf. I'm all about getting things done in the least ammount of time and imho cf blows everything else away for speed of development on most web applications and surely for working with xml! I'm sure the xml support in cf will continue to get better in future versions. I'll never go back.
  • 5 Nathan Dintenfass // Sep 8, 2004 at 5:04 PM

    I'm not sure the issue is so much that it's too hard, but that it's a lot easier to morph your XML in your language of choice.<br /><br />Sure, XSLT transformations can be MUCH faster than, say, a CFML script that traverses from XML, but most developers are rarely dealing with very large XML documents AND need it to be as fast as possible AND need the abstraction capabilities of XSLT AND need the environment-neutrality of XSLT, so it's just not worth most people's time to put the time into learning it.<br /><br />I have heard of XSLT being used to great effect, though, for applications that make strict separation between display and "business logic". I bet if you could generate decent RIA interfaces without ever needing to fire up the Flash GUI that you might start seeing more sites using XSLT to generate HTML/SWF/WAP/etc UIs as part of their build process (or even at run time, as I've seen some sites do).<br /><br />Bottom line: the pain of learning and implementing XSLT almost always outweighs the benefits it would have relative to just building some scripts to do what you need to do.
  • 6 Massimo Foti // Sep 8, 2004 at 5:04 PM

    I am with Nathan on this and my opinions on XSLT predate Fowler by a few years :-)<br /><br />I can hack XSLT, but I rarely use it. I think the main problem with it is that people try to use it for everything and, while it's Touring complete, implementing any serious logic with XSLT is a pain. The fact that it's possible to do it doesn't mean it's a good idea.<br /><br />All in all, whenever I need to manipulate XML I prefer another language. I am used to DOM programming since years si initially XML in CFML sounds weird, in the end I realized it's very "fusionesque", simple, yert powerful and, in case I need it, I can still go back to DOM programming using the Java API.
  • 7 Sam // Sep 8, 2004 at 5:04 PM

    I don't think XSLT is hard so much as it is just different. XSLT is based on a whole pattern matching and replacement methodology whereas almost everything else we're used to is procedural or object based. <br /><br />I personally think XSLT is actually really simple __once you get used to it__. It has a huge learning curve, but once over that curve it's great. In the areas I've used XSLT, I've always managed to do using less than 1/10 the code that would be required using DOM (but of course CFMX XML is a huge advantage over standard DOM). <br /><br />In one example we were working with SOAP in CF5 and a co-worker spent six hours trying to program MSXML DOM parsing code to read the complex SOAP packet. When it didn't work we turned to XSLT and in less than a half hour had a fully working XSLT to convert SOAP to WDDX and then used CFWDDX to parse it. The final solution was much smaller, faster, and easier to maintain (for someone that knows XSLT of course).<br /><br />I'm not in the camp that think XSLT is the be-all programming language--nothing is. But it's a great tool to have available.<br /><br />My $0.02<br /><br />Sam
  • 8 mark // Sep 8, 2004 at 5:04 PM

    I have to totally agree with Sam on this one.<br /><br />I've built entire presentation layers in XSL - it wasn't the most fun thing in the world - because (I don't feel anyway) that XSL should be used in that broad a scope.<br /><br />When XSL is used for a specific purpose in a particular application, it can be a very elegent solution for dealing with XML.<br /><br />But the notion that something is 'too hard' - is just rediculous. Anything is just as hard as the time you are willing to put into it.<br /><br />But to try and take XSL across the boarder, and try and make it do everything a scripting language can, is going to cause you more headaches than it's worth (in my opinion).
  • 9 Scott Keene // Sep 8, 2004 at 5:04 PM

    For me the value of XSLT is in the T. Being able to transform XML into multiple representations is a real benefit in many situations, some of which have been described by Jesse and Sam. Being able to then change that on the fly with no mods to program code is icing on the cake.<br /><br />That said, the learning curve is certainly steep. For me, it was worth it and I am now comfortable with XSLT. There are no silver bullets, though, and so, like most other things, it's a case of "use when appropriate". Whether it is too hard or not, that may be subjective!
  • 10 Andreas Ryge // Sep 8, 2004 at 5:04 PM

    I have used XSLT for generating things like RTF documents. I have found that XSLT is simple, easy to learn. But I've allways had to do all the advanced stuff in scripts - like sorting nodes based on keys in other nodes. Just try to transform an unsorted table into a sorted table. IMHO XSLT isn't powerfull enough.
  • 11 Ray Wilson // Apr 17, 2007 at 12:21 PM

    XSLT has a slight leearning curve but is a very powerful tool to have in your tool belt. The book by Michael Kay (XSLT 2nd Edition WROX) is an essential learning tool IMHO. No one understands or helps you learn XSLT like Mike. Struts-wise being able to turn a record set into XML and then store that string in a Request attribute for several other tags to use (via XSLT) is a very useful, fast, light weight web technique. Being able to model your transformation in a web browser is another big plus. Change and view, change and view without a tedious compile step in between. I use XSLT in Tags all the time to produce HTML from stored XML and it is fast and very flexible and easy (yes once you get the hang of it). It's worth learning and using.
  • 12 Michael Hill // Sep 18, 2007 at 5:44 PM

    XSLT is extremely tough for most useful task that is simple to do using a programming language. I know the "extensibility" part what makes it click but most programmers already know how to program rather easily. I feel sorry for someone who has inherited a project based on XSLT that was abandoned by another programmer; It's like working in a DOS command prompt without knowing the current directory context and having to having to find files in other directories using only relative paths (at least thats how it feels).
  • 13 TANK Oliver // May 29, 2012 at 7:08 AM

    The problem of hard languages such as XSLT is that one can achieve the same task in a too many ways. That subsequently makes it difficult to understand/preview at the 1st glance what a XSLT script is intended to produce. The maintenance is therefore too much pain. A better transformation engine should offer as few concepts as possible and the concepts should be as simple as possible while preserving the capabilities. I think that the metamodel of generatexy ( is almost minimal and should be considered as a starting point to build a standard enhanced XML transformation language.