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.

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.

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.

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.

AND/OR

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.

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.