programming and human factors
by Jeff Atwood
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:
All of this site is written in simple XML documents and transformed to HTML. I find this works really well, and means I never have to worry about dealing with HTML formats. (Not that fancy layout is my style, as you can tell.) I've even written a whole book that way.For most of this time I've used XSLT as my transformation language. I've got pretty good with slinging XSLT around and getting it to do what I want.
But no more.
When I wrote the software for this Bliki (on a long flight) I did it in Ruby. Prior to that I used Ruby to do a new version of my home page. My conclusion from this exercise was that using Ruby for XML transforms was much easier than using XSLT.
I've had almost the same exact argument with a few developers I used to work with. After working through a bit of the XSLT necessary to accomplish something, I concluded that it was easier and simpler to use procedural code to do the same thing. Not always, of course, but most of the time. As Fowler points out, this does beg the question: what good is XSLT?
I think this may raise some real questions about XSLT. There's still much I like about the power of XSLT, but I hate the syntax and the walls you keep running into. I'm not going to convert my whole site over to Ruby tomorrow - most of the XSLT works fine - but I can certainly see my way to doing that at some point in the future. But the bigger question is whether you're better off with scripting language for this kind of task than XSLT.
Maybe the idea of XSLT transforming XML into "anything" is fundamentally unrealistic-- just more Write Once, Run Anywhere snake oil.
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.
Josh Carlisle
Josh Carlisle on July 5, 2005 10:06 AMI 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...)
Mike Shaffer on July 6, 2005 9:51 AMI 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.
(Ever program in Prolog? It is horrible.)
Ole Eichhorn on July 6, 2005 12:44 PMThat'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.
Jeff Atwood on July 6, 2005 1:57 PMThat'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.
Will Rickards on July 8, 2005 5:56 AMThat is exactly the scenario where I apply XSLT.
This sounds good to me. Can you blog an example? It seems the key is linking the XSLT to C# extensions to do the hard parts.. how is that done?
Jeff Atwood on July 8, 2005 6:49 AMHere's another random example of why XSLT is often a PITA:
http://www.nedbatchelder.com/blog/20050623T160101.html
Jeff Atwood on July 8, 2005 10:35 AMSome comments on this from Adam Bosworth:
http://www.cs.ust.hk/vldb2002/VLDB2002-proceedings/papers/S01P01.pdf
---
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.
Robert Rossney on July 31, 2006 11:59 AMI completely agree.
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.
Karthik Hariharan on August 1, 2006 8:01 AMThe 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.
dennis on August 8, 2006 9:30 AMIf you're looking for a curious case, checout WML at http://www.wesnoth.org/wiki/ReferenceWML
Joshua on August 29, 2007 12:17 PMPersonally, 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.
What do you think?
Al on September 1, 2007 12:21 PMnow imagine me wrinting a RTF-GNML converter almost fully in XSLT , alone, for a year...
well my friend. I read your blog almost everyday, and I haven't seem such a "Coding Horror" as this =-P
Daniel Monteiro on September 27, 2007 7:58 AMComing 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!
Ben on September 28, 2007 7:47 AMIf 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.
yer wrong on May 24, 2008 4:15 AMGoogle has code here that is inline with what I just said in the previous post.
http://goog-ajaxslt.sourceforge.net/
use the tool on May 24, 2008 4:18 AMI learned HTML by reading the official documentation from W3C. Of course understanding XPath was a prerequisite, so I read XPath first. The documentation was at the right level of complexity and I'd say for the most part well written.
I later had to use my knowledge and I could see how colleagues disliked it because they had trouble wrapping their minds around various simple tasks. I had no trouble approaching these tasks, mainly because I read the documentation. (Most of their issues stemmed from misunderstanding on how an XPath selector's result is acted upon template invocation; pure mechanics.)
XSLT does well what it's meant to do, which is XML transformations. I didn't really see the promise of panacea for data transformation anywhere, so is somebody here expecting too much of it?
I fear many technologies are well intended but they fail to live on because not all of us are technical and, let's face it, users and usage are the ultimate judge of a technology's destiny. Good is very, very relative, and while XSLT is good it may be that it hasn't touched that cord to yield the good resonancy.
I've had similar reactions to other XML technologies that I pushed forward as an employee, like XML namespaces.
Mihai on December 3, 2008 5:05 AMs/HTML/XSLT/
Mihai on December 3, 2008 5:05 AMxslt is great. it has a small upfront cost to learn it, but it lets you build an incredible transformation layer. my only potential issue with it is speed.
Ivan on February 5, 2009 9:46 AMIt'd be great if the commenters could all come back and update their comments to say whether they're talking about XSLT 1.0 or 2.0. They are two different languages: 1.0 can be a right PITA is you try to stray outside its narrow bounds; 2.0 is a lot better though, of course, still pretty verbose. It's a pity 2.0 is not more widely implemented, particularly client-side.
As to the comment about getting XSLT through Michael Kay's books: yes, I find they're pretty much essential and have found the little else I've read has tended to be simplistic and misleading.
Ed Davies on February 5, 2009 10:53 AMJeff,
All the hard stuff should be done in c# extensions at the top of the XSLT file. We had a case where we were transforming XML in WordML and we wanted to generate a graph based on a node set in the XML. Obviously we weren't going to generate the graph in XSLT. So, we passed the nodeset to a c# extension method which sent the nodeset to a ASPX page which consumed the XML, generated a graph using a 3rd party tool which then saved it as a JPEG. We streamed the JPEG back into the XSLT as base64 and there it was when you opened the Word file. Magical!
Chris P on February 11, 2009 9:14 AMI hate XSLT too.
To me, XSLT is about as intuitive as doing brain surgery while drunk.
I much prefer HTML generation using PHP.
Evan Plaice on March 3, 2009 10:24 AMI read your blog, although I am a java-programmer, because of your insights into programming. You write well and if I get to know a bit of .net on the way, that's fine by me. Your writing on RegExps for example, can easily be applied to Java as well.
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. Don't we have enough of mud-slinging between different languages as it is? I like Java a lot, but I'm sure that I could like for example c# as well. There is no contradiction in that.
What relevance does a four year old article have in this world anyway? What relevance would such an article about .net have? Slim to none, is my somewhat uneducated guess.
Well, just wanted to let you know. As I said, I like your blog a lot anyways.
regards
martin
The comments to this entry are closed.
Subscribe in a reader
Subscribe via email
|
|
Traffic Stats |