I had a look at XSLT for transforming one XML file into another one (HTML, etc.). Now while I see that there are benefits to XSLT (being a standardized and used tool) I am reluctant for a couple of reasons

  • XSLT processors seem to be quite huge / resource hungry
  • XML is a bad notation for programming and thats what XSLT is all about.

It do not want to troll XSLT here though I just want to point out what I dislike about it to give you an idea of what I would expect from an alternative.

Having some Lisp background I wonder whether there are better ways for tree-structure transformations based upon some lisp. I have seen references to DSSSL, sadly most links about DSSSL are dead so its already challenging to see some code that illustrates it. Is DSSSL still in use? I remember that I had installed openjade once when checking out docbook stuff.

Jeff Atwood's blog post seems to hint upon using Ruby instead of XSLT.

Are there any sane ways to do XML transformations similar to XSLT in a non-xml programming language? I would be open for input on

  • Useful libraries for scripting languages that facilitate XML transformations
  • especially (but not exclusively) lisp-like transformation languages, or Ruby, etc.

A few things I found so far:

closed as off-topic by gnat, GlenH7, user40980, World Engineer Oct 23 '13 at 14:22

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions asking us to recommend a tool, library or favorite off-site resource are off-topic for Programmers as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it." – gnat, GlenH7, Community, World Engineer
If this question can be reworded to fit the rules in the help center, please edit the question.

  • I use HXT and Haskell quite often, it's very pleasant – jozefg Sep 10 '13 at 17:23
  • 5
    In all fairness, it's not Jeff Atwood who's advocating Ruby, he's quoting Martin Fowler who prefers Ruby. The original post by Fowler is here: martinfowler.com/bliki/MovingAwayFromXslt.html And it was written 10 years ago in 2003 - I think XSLT 2.0 came out in 2007 and with many improvements, and XPath 2.0 in 2010. – FrustratedWithFormsDesigner Sep 10 '13 at 18:06

It's difficult to assess technologies when you don't have deep experience of them, but of course that's exactly when you have to make your decisions, so there's no simple answer to that dilemma.

You cite two concerns: performance and usability. I'll try to address both below.

Firstly, performance. Performance of course depends not only on the language but also on the implementation, and also on the expertise of the users. Different XSLT processors can vary widely in performance, and the same processor can vary widely depending on how it is used (with Saxon, for example, people who have performance problems are very often found to be using it with DOM, which is a poor combination, and performance can increase ten-fold if you use Saxon's native tree model instead). So the first advice is don't take performance on hearsay, measure it; and the second advice is to make sure that the person doing the measuring has enough experience not to make silly mistakes. More easily said than done.

Crudely, you can separate transformation jobs into two categories: simple and complex. For simple transformations, with a good XSLT processor the time is all spent parsing and serializing and the XSLT processing time hardly comes into the picture. Since any other technology is going to incur the same parsing and serialization costs, the choice of transformation technology isn't going to make a big difference (except perhaps very for very low-level coding using streaming, but not many people can afford the programming time and skills needed to implement that). For complex transformations on large documents, you start to get the same issues as with SQL programming: achieving good performance requires good interaction between the skills and knowledge of the programmer, and the capabilities of the optimizer. As with SQL, it's very easy in such a high-level language to write a few simple statements that result in the processor having to do a very large amount of work. But also as with SQL, programmers who know what they are doing will do much better than novices.

Second, usability. The XML-based syntax for XSLT is very off-putting to a lot of people on first encounter with the language. But there are good reasons and real benefits for doing it this way: there is the "template" argument, that a lot of the code consists of XML to be written to the result document, and the best way to write XML is in XML. And there is the "reflection" argument; in large complex systems, it is very common to find stylesheets that generate stylesheets. Then there is the "tools" argument; if you are in an XML shop, you probably have a lot of XML tooling such as syntax-directed editors, and it's good to be able to use the same tools to handle your programs and your data. The disadvantages turn out to be fairly cosmetic in comparison: there's the number of keystrokes involved in editing (easily fixed with a good editing tool), and there's the verbosity of the code (reducing its readability). The verbosity is vastly reduced in XSLT 2.0 with the introduction of features such as regular expressions and stylesheet functions: many stylesheets are reduced to a half or a third in size when they take full advantage of XSLT 2.0.

Your mention of DSSSL leaves me with a wry smile. I've never used DSSSL, but the stories I heard were that it was unsuceessful because its syntax was arcane, and unrelated to the syntax of the data (SGML). The use of an XML syntax for XSLT was strongly motivated by experience with DSSSL.

There are people who love XSLT and there are people who hate it. Unsurprisingly, those who use it a lot tend to fall into the first category. Those who dislike it are generally those who haven't learnt to "think the XSLT way". You could argue that a programming language shouldn't affect the way you think, but it does: writing in a rule-based language takes a different mindset from writing in an imperative language. The first reaction of many programmers is that they feel less in control (describing the problem, rather than telling the computer what to do step by step). It's very similar to the reaction you used to see when people were first introduced to SQL. These days, people learn SQL earlier in their careers so there's less mental readjustment required.

Ultimately, you should choose a technology based on objective measurable criteria, not on love/hate reactions. It's difficult to make those measurements. But there are lots of people using XSLT very intensively and very successfully, so there is no doubt that it can be done.

  • 2
    The more common term for "Rule based language" is a declarative language. – jozefg Sep 10 '13 at 20:48
  • @Michael Kay - Well put. I personally love XSLT and use it with C#. In addition I use it with XSL-FO to product PDF documents. XSLT is powerful, very powerful, allowing me to convert large amounts of data quickly into HTML, XSL-FO, XML or Text. – PhillyNJ Sep 10 '13 at 21:50

Without additional information about the context, it's difficult to answer.

Still, I don't understand why you don't want to use XSLT. It's the right tool for the job, and a powerful one. It is done specifically to transform one XML into another.

XSLT processors seem to be quite huge / resource hungry

Do you have hard data to support that? Have you implemented the solution using XSLT and found that XSLT is the bottleneck which makes it impossible to deliver the product while fulfilling all the non-functional requirements related to performance?

Without statistical data and profiling, you can't reasonably assert that a given solution won't work. Are the non-functional requirements reasonable enough? Would you prefer wasting, say, ten days of developers' work to gain a few hundreds of milliseconds by replacing XSLT by another alternative? Does it worth it?

XML is a bad notation for programming and thats what XSLT is all about.

So you want to transform one XML into another, but don't want to use XSLT because "XML is a bad notation"?

If it's the fact that you use XML as a sort of programming language which annoy you so much, see it not as programming, but rather a bunch of transformation rules.

You don't even need to write XSLT by hand. There are plenty of ETL editors which can let you map graphically one XML into antother: no programming required whatsoever. Some of them use XSLT as output.

  • I have encountered resource problems with XSLT based sheets, they were created with a graphical tool yet it stopped working with bigger files. – wirrbel Sep 10 '13 at 18:14
  • 1
    then there are probably issues with your XSLT file not XSLT Transformations themselves – Malachi Sep 10 '13 at 18:23
  • Now I am not condemning XML, in fact I think it is appropriate for data representation (especially for markup). As a "programming language" - and XSLT is a domain specific programming language - it is inconvenient. <xsl:whatever > Tags, metalanguages (like xpath, $ notation, etc.) in the query attributes, everything that is not mapped into XML is being put in attribute quotes. For an impression of an s-expression representation of XML: blog.getprismatic.com/blog/2013/1/22/… in such away can XML and and proglang work seemless – wirrbel Sep 10 '13 at 18:28

If you are using XSLT to generate XML based on the raw XSLT and some parameters that you are passing to the XSLT engine, then using a templating XML approach is much easier to understand and maintain.

I've been on a project where Moustache was used to replace XSLT and the result was much simpler base XML files that everyone could edit and adjust, rather than that project work being passed to one or two brave souls, who would sit in total silence with beads of sweat pouring off...

The template approach is not suitable for use when the base XML is also valid data in its own right, and that XSLT is being used to provide an alternative representation, or an extract from the source XML.

  • would you mind explaining more on what it does and why do you recommend it as answering the question asked? "Link-only answers" are not quite welcome at Stack Exchange – gnat Oct 23 '13 at 7:47
  • 1
    reviewed answer inline with your feedback – Michael Shaw Oct 24 '13 at 10:40

XML is not a Programming Language

XML is a way to Transfer/Transport Data.
what an XSLT instruction does is use Xpath to query the Data in a specific way and put it into another Data Transport Object/Document.


XSLT can transform your XML into HTML, which is another way to display/transport the Data contained in an XML Document.

if you are looking to Change the XML, or Create an XML Document then you could use any number of languages: C#, VB, Ruby, Etc.

usually when you use an XSLT file to transform an XML Document you still have the original XML Document, you don't actually change the original Document, you really create a new one.

  • 1
    Wikipedia says: "XSLT is a Turing-complete language, meaning it can specify any computation that can be performed by a computer.". I never said that XML was a programming language per se. – wirrbel Sep 10 '13 at 18:32
  • you said "XML is a bad notation for programming" in programming languages that I have used you can pull Data From XML Files rather Easily. XSLT is Gaining Ground on being able to do a lot of Computations and spitting out that Data to another Data Transport object/Document. it is like SQL to SQL Server it can do a lot of stuff but it is mostly back end, not front end. SQL like XSLT, it queries Data in a specific way, but you never want to give the results of that query as a report, you want to send the information to a report builder – Malachi Sep 10 '13 at 18:41
  • 2
    XSLT doesn't query data, XPATH does the querying. Isn't XSLT a declarative language which defines instructions on parsed xml? – PhillyNJ Sep 10 '13 at 19:17
  • XSLT defines transformation rules based on patterns for which it can use Xpath. I.e. you can have high level programming constructs such as xsl:for-each xsl:apply-templates, xsl:if xsl:call-template xsl:value-of to define transformation rules. – wirrbel Sep 10 '13 at 19:26
  • 1
    @PhilVallone I agree. I was wrong there. wirrbel, I am not going to argue with you about what XSLT/XSL is and isn't, if you want to transform your XML document into another XML Document you are going to want to use XSLT/XSL. – Malachi Sep 10 '13 at 20:35

I've worked on multiple XML processing systems that combine XSLT libraries with Java or C++ for the parts that XSLT isn't as good at. There are libraries that get very good XSLT performance even on 20 MB XML files, however XSLT has some limitation with context, variables and really complex string patterns. Each system I've worked on had a few things done in Java/C++ because context was important or some complex regex expression helped. My takeaway is that XSLT plus some additional code in your language of choice is a good way to transform XML.

Not the answer you're looking for? Browse other questions tagged or ask your own question.