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 reasonsXSLT processors seem to be quite huge / resource hungryXML 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 onUseful libraries for scripting languages that facilitate XML transformationsespecially (but not exclusively) lisp-like transformation languages, or Ruby, etc.A few things I found so far:A couple of places on the web have pointed out Linq as a possible alternative. Quite generally I  any kind of classifications, also from those who have had the best XSLT experience.For scheme http://cs.brown.edu/~sk/Publications/Papers/Published/kk-sxslt/ and http://www.okmij.org/ftp/Scheme/xml.html
XSLT and possible alternatives
xml;lisp;linq;xslt
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.