When is XSLT an appropriate solution for defining XML transforms instead of using a scripting language like Python?

Question

When is XSLT an appropriate solution for defining XML transforms instead of using a scripting language like Python?

Answer 1

It's mainly to do with XML being a hierarchical tree sort of data structure.

You can set operations to happen when certain patterns are matched wherever they appear in the tree of an XML file.
You can also cascade transformations so certain ones get applied/ignored depending on preceding operations further up the tree.

If your XML data is relatively flat and a tag of <X> means the samething everywhere then the advantages aren't as clear, but if <X> means one thing at the root and a different thing inside a <Y> and something else if it's inside a <Z> after a <y> then XSLT becomes much easier.

Answer 2

There is a great deal of overlap.

• If you can specify a smaller number of template rules than it takes to recursively define the same behavior with code, then XSLT makes sense.
• If the person maintaining the rules long-term is more comfortable and familiar with (or has better tools to support) code than XML/XSLT, then code is the better way to go.
• If you want to be able to support massive parallelism for better performance, then XSLT (or a functional language like F#) may be the way to go, though that may not be practically available right now (though it should in the future).

Answer 3

I find that XSLT is very useful for simple jobs and it is also platform-independent (XSLT is built into many languages). However I don't find it scales easily and since I also need to do domain-specific computation it is very tedious to write normal operations in the recursive functional manner.

Also XSLT2.0 is really necessary for operations such as grouping (without it you have to remember the Muenchian method which is clever but non-intuitive). However not all systems support XSLT2.0.

Answer 4

If you don't want to consider things like developer familiarity, I would say pretty much always, assuming you have XSLT 2.0 or at least EXSLT, as XSLT 1.0 is pretty limiting (if you only need structural transformations, 1.0 suffices, but if you need to do anything with the content, you want to stay far away from 1.0). XSLT is specifically designed for transforming XML, and I have found it a lot better for that task than XML libraries in general-purpose programming languages.

Of course, that's all assuming that you only need to transform input XML into some other form. In the real world, requirements change, and suddenly you end up not only having to transform the XML but also perform some operations based on it. And though XSLT is Turing-complete, it's not really a general-purpose programming language, so for future-proofing it might be safer to use another language. Still, I would probably implement the first version in XSLT because I find it faster and easier to understand, and only if XSLT later on proves unsuitable would I consider something else.

Answer 5

Performance-wise, some XSL processors compile the transform into binary before running it. If the transform will be used many times, that can be a large performance advantage.

Answer 6

Right off the bat, if you're transforming the XML into anything other than HTML, XML, or text, XSLT's not what you should use.

Other than that, I've done a ton of work with XSLT, and I have yet to run into a case where I've used XSLT to transform XML and found myself wishing I'd picked something else. As with jk, my answer's "pretty much always."

Answer 7

If you or someone you are working with is more comfortable in XSLT, or if there is some technical benefit you'd gain from using XSLT (integrating the XSLT into Cocoon, for example), then use XSLT. Otherwise, it's almost always more of a pain than you think it will be. You'll be much happier using a language like Python (with lxml), Ruby (with rexml) or even PHP (with SimpleXML). You can even pair it with a templating library (like genshi, with Python) to make the job even easier.

Having taken both approaches myself, I feel confident that you'll be happier in the long run using something other than XSLT.