I have no problem with XML. It's a fine way to store hierarchical data in a relatively simple, mostly human-readable format. But I've always disliked its companion technology, XSLT. While useful in theory-- "using a simple XSLT transform, XML can be converted into anything!"-- in practice, it takes painful contortions to do anything practical. Evidently I'm not alone; Martin Fowler hates XSLT too:
I would agree that XSLT if fairly painful to learn especially from the perspective of moving from a procedural mindset to a declarative but I’ve had really good luck with it when it comes to using it for simple to moderately difficult code generation tasks. I picked it over quite a few proprietary techniques simply because it’s so widely supported and there was tons of documentation and examples readily available out there. Now don’t get me wrong I won’t building any applications around it any time soon (nor would I recommend it) and it was less then a joy to work with but I found once I got going and switched gears a bit it wasn’t too bad. For a short time I played with the short lived MS implementation of XQuery in .Net 2.0 and I really like what I saw (procedural) as an alternative to many aspects of XSLT but it was unfortunate that MS decided to drop XQuery from .Net 2.0 (outside of VS 2005) because it wasn’t yet ratified by the powers that be. I haven’t taken a look at other XQuery implementations nor have I checked out Ruby but I think I’m going to have to add it to my rainy day list.
I don’t see how you can conclude that Martin Fowler hates XSLT. I’d say he simply, for some tasks finds Ruby easier to use.
In my experience, scripting languages like Python and Ruby can (and are) be used to transform XML into text (mostly C++/C# code) in some simple cases. As soon as complexity increases XSLT becomes a lot easier. It depends heavily on what you are doing.
I also know that many people coming from imperative languages world (practically all modern languages, C based, VB variants, all scripting ones) are scared of XSLT as it is very different, and that’s OK. Once you truly understand XSLT and apply it in proper context, it is a great language.
I assume that now that .NET will bring a lot faster performance and transparent debugging of XSLT that more developers will try it.
Jeff - right on! The problem with XSL/XSLT is that you have to switch modes from the procedural to, well whatever you’d describe XSL as. XSL’s strength is it’s natural recursion and understanding of XML in general. However, alot of XSL that I’ve seen written is to convert raw XML data into HTML, and alot of it is very procedural in nature. Using loops with iterators, if’s and otherwise’s, stuff that is just nasty in XSL. Where I work, it’s always called from a procedural language be it Java or Javascript. I’ve argued relentlessly that sticking in the native language is just as fast (preformance-wise) and faster to develop. XSL is just a pain in my eyes and I’m anxious to look at it from a Ruby POV (beginning to look at Rails, just for fun).
It does reek of the WORA (Debug Forever) mantra of the early Java era. To defend your position, I think it’s fair to link to an old Java article. The WORA idea was crazy at best and XSL and a few others are falling into that same trap. I’m a Java developer (SWT RCP, go Eclipse!) so I can identify with Martin’s concern. But I think we need to separate the Java vs. C#, 'nix vs. Windows, etc… and realize something: If we don’t understand the past, we’re bound to repeat it. (To paraphrase…)
I agree 100% with this post, and this hits at exactly the weakness of XAML. Everyone assumes just because something is declarative rather than procedural that it will be easier to code and maintain. Not true.
That’s why I just find it below you to link to a four year old article bashing Java, it just seems silly to me.
I wasn’t bashing Java, just the idea of Write Once Run Anywhere-- it’s a bad idea. Moreover, it’s unnecessary 90% of the time.
I don’t see how you can conclude that Martin Fowler hates XSLT. I’d say he simply, for some tasks finds Ruby easier to use.
It’s true that “hate” is probably too strong of a word; I just chose that for dramatic effect. But he clearly has serious misgivings about XSLT based on lots of prior experience with it. So much so that he wonders if XSLT itself is even worthwhile! That may not be “hate” but it’s serious.
As soon as complexity increases XSLT becomes a lot easier
That’s interesting, because I think it’s the other way around: as the transformation becomes more difficult, XSLT gets harder. There is a lot of anecdotal evidence to support this-- date handling edge conditions, for one.
that sticking in the native language is just as fast (preformance-wise) and faster to develop
This is a classic argument for consistency. I only like mini-languages where they actually buy me something – eg, they save me from writing a lot of extra code. Regex and SQL are examples of embedded mini-languages that save a lot of procedural coding. I don’t find XSLT convincing in this regard… I always feel that it would have been simpler and easier procedurally, and certainly not a significant code savings over the procedural equivalent.
That’s interesting, because I think it’s the other way around: as the transformation becomes more difficult, XSLT gets harder
Not in some of the cases I had. In fact, when I was assigned to a particular task (in short, transform from XML to nicely indented text) there already was a “pure” C++ solution in place using SAX API.
The final XSLT solution was so much easier you wouldn’t beleive it.
There is a lot of anecdotal evidence to support this-- date handling edge conditions, for one.
For date handling and such, I use extensions. Actually, if you need to perform anything reasonably complex with the data itself, you should use extensions (C++/C#/Java). When you need to operate on the structure, then use XSLT. Combine judiciously and you’ll get the best results.
I only like mini-languages where they actually buy me something – eg, they save me from writing a lot of extra code.
That is exactly the scenario where I apply XSLT.
I’ve programmed in Prolog in college. It doesn’t really compare to XSL. Prolog is much more difficult.
But the context switch that happens when designing xsl versus designing in procedural languages is significant. SQL is similar but not nearly as bad.
Like any language experience helps and you get used to thinking in certain ways.
Definitely agree that xsl should be used for structure transformations mostly and that any data manipulation should happen some place else.
A good example of this is XSLT. It started out as 2 simple visions by 2 groups. We (at Microsoft) wanted an XML Transform language that would typically take input documents with well-known schema and transform them into other documents also typically with well-known schema. Others (Sharon Adler, James Clark, …) wanted a language that would take semi-structured unpredictable input schemas and generate rich output UI. What is more, some things that we all wanted to do were hard. The result was an overly complex language all because of the desire to avoid code. Code is good. All great products have been procedurally extensible. In your own worlds, you all learned (or were sometimes force-fed) the importance of being able to extend SQL with code whether it was PLSQL or Transact SQL or SQL J.
There’s a substantial gulf between getting pretty good at getting XSLT to do what you want and actually getting XSLT. I’ve done an enormous amount of XSLT development, and I’ve trained a lot of developers in using XSLT, and it’s clear to me that there is a point with XSLT where you just get it.
It took me about a year. It would have taken less if Michael Kay’s book had been published sooner, but there you are.
Despite what Adam Bosworth says, XSLT isn’t overly complex. The things that consistently make it hard to use mostly come it from being too simple: the poor inventory of string functions, the absence of date handling, the terrible inconsistency of XML document fragments. (And, of course, the awfulness that is XSL-WD. When I feel inclined to hate Microsoft, that’s the itch I scratch.)
XSLT is like SQL: it is a profound and powerful set of tools for performing a set of tasks that can be accomplished procedurally but generally should not be. As with any good tool, you need to understand how to use it, and you need to be able to recognize what jobs it’s good for.
After 3 months of trying to make XSLT do dances it was never meant to do, my team made the decision to re-write many of the pages of our web app which were based on XSLT transforms back into straight HTML.
No more crappy templates,horrible code debugging, and reliance on transforms which spit out noncompliant XHTML.
The silver bullet that allowed us to do this? XQuery.
The problem with XSLT is that it’s a functional language, without all the facilities that real functional languages provide. Learn Lisp, and XSLT will look like the work of amateurs.
Not to mention, any programming language that requires keywords to be written twice, just to satisfy the syntax, is the work of the Devil.
Personally, I like XSLT when the data I have is consistant, but the transformation needs to be handled dynamically. One such instance was a customer based email delivery system for a company I worked for. The idea was that we needed to deliver custom emails to customers that relayed their information every month or so, tied into one of the several services the company provided. Since there were many applications with their own databases, the plan was to build XSLT templates to render HTML, with a [field] interface to link database fields in mail lists. When the XSLT template was built, regex expressions replaced the [field] information with XSLT references, and then the .NET XSLT transform system would merge the documents into a deliverable email body.
What was GOOD about this, is that we now had a way to link any database query to an HTML template. What was BAD about it is that unfortunately, unless you had someone on staff with cursory knowledge of XSLT, the template building routines were a little tricky to follow without extensive documentation to the process.
In the end, I personally think it was a good way to exploit the technology that was around me. While I could have done it procedurally, ultimate the template system would have needed to link to the database source, and be, in effect, a system much like XSLT. I didn’t see the need to invent the wheel, and not have the benefit of the “optimized” XSLT transform routines that .NET provides.
Coming in a bit late here but whats good with it is that you can have people that do not know programming to build templates, I think thats the main purpose, a declarative programming syntax that can perform complex tasks but do not require the person to be a programmer.
Also, how would you build a fully localized website without xsl templates and tranformations ? All we have to do is output the xml in another language and everything works, can you do that without a lot of complexity in pure ASP.NET, PHP…whatever, I think not.
a declarative programming syntax that can perform complex tasks but do not require the person to be a programmer.
Huh?
If it takes a developer a year to ‘get’ XSLT (see comment from Robert Rossney), I can’t see a non-programmer getting anything at all.
This is why XSLT will never catch on the way HTML did - HTML (or rather browsers) is incredibly forgiving. XSLT is incredibly brittle. And unreadable, and unmaintainable.
However, one area where I have made good use of XSLT is transforming XML RAW output from sql into usable XML. I.e flat to hierarchical structure, or pruning empty branches from a tree etc. the XSLT is short and sweet, and the results come out fast.
But you’d better make sure it works right, because if you come back 6 months later, don’t expect to understand what you wrote!
If you know how to generate html using xslt from a well defined xml then do it. The biggest thing I like about using xslt is that you can offload the work to the client browser to render the html since most of them have xslt support. All your server needs to do is pump out the xml to the browser. You can also use ajax to obtain the xml from the server and let the browser render the view using client-side xslt processing. I have built web apps this way with minimal processing overhead to the server.
There seems a trend that everyone is a sheep in regards to what Fowler has to say.