Viable alternative to XSLT?

Question

I have used XSLT for a few different things over the years. I got used to it, but never felt like I really understood it all the way through. It always seems like I have to experiment to get the result I want, and the outcome isn't necessarily a logical conclusion in hindsight.

On top of that, the one or two times I had to turn over something written using XLST to someone else, it represented a huge barrier to entry. Functional programming is unfamiliar to the average coder or scripter and the learning curve is very steep.

XML is here to stay, and there will always be a need to manipulate it somehow. There are frameworks that use XML that are perhaps less used than they could be because they lean heavily on XSLT for presentation.

I am not opposed to XPATH. In fact, I consider it to be straightforward and quite useful.

I mostly work in Java and Python, but I'm more concerned with the general problem of how to work with XML without needing XSLT. If there is an effective set of tools for dealing with this in C#, for instance, then that's a start.

So, is there an alternative?

Answer 1

Yes the .NET framework has a whole range of tools appropriate to various scenarios.

Linq.Xml, XPathDocument, Readers and Writers, Serialisation not to mention the typical Dom implementation.

Answer 2

.NET has an entire System.Xml namespace dedicated to XML parsing and manipulation. All modern languages have libraries like that, and they all work in similar ways because XML is a well-defined strict standard.

That said, when you're dealing with converting one XML document to another format, XSLT is the best language for the job because that's what it was designed to do. Other languages can do it, sure, but the code will be bulkier and perhaps less straightforward.

As an aside I would say that XSLT and functional programming in general is something you just have to get to be a good programmer. If you're having trouble with it, brush up again on the basics. Learn LISP or Scheme and XSLT will seem trivial.

Answer 3

While using XSLT quite often and intenseley I have also written a lot of code that loads XML into a DOM. This was Python or C# code in my case ...

Depending on the Job sometimes XSLT is the better tool (when you're generating lots of output and need it for templating) and sometimes operation on the DOM is faster and easier to understand (when you need to do deep restrucuring of the order of elements).

When you program against the DOM you can still use XPath.

Of course there also are some other templating engines that grok XML but they haven't really appealed to me. They also have a learning curve to other developers and in our team everybody can read a little XSL, some can write it (when we need to to XSL instead of using the DOM).

Answer 4

It depends on your need. If you're talking about simply changing the shape of the data, XSLT is your best option. It does have a high barrier of entry. I spent an entire year as an architect tilting at windmills trying to find developers who were even willing to be trained on XSLT. You really don't have a good alternative, though.

If you're trying to change both the shape and nature of the data (meaning translating values as well as transforming data), you're probably best suited picking the language of choice and writing code. A good alternative if you have a tool available is to use an ETL tool that supports XML transformations. It will allow you to visually design the transformation. They could very well be using XSLT in the back-end, though.

Answer 5

I prefer to do XSLT-like work in Python. There are several good XML parsers. The ElementTree parser, in particular, supports a useful subset of XPath queries.

Often, it's easiest to create proper Python objects out of the source XML document. Then the manipulations are just Python programming. Each Python class definition can be defined with methods to emit the Python objects in the desired target notation.

Answer 6

I've dabbled with XSLT for transforming XML into HTML and PDF (via XSL:FO and FOP) for producing reports, and I found that I was being taxed a very high intellectual burden to not quite get the results I wanted. I would also have feared explaining it all to someone else, or have someone else maintain what I'd done.

So I switched to using an XML parser to programmatically load the DOM as Java objects and then onwards from there to HTML and XSL:FO. Eventually we ditched the XSL:FO part for iText.

Viable alterative to XSLT? Parse it and do the leg work in whatever language floats your boat. It's far more flexible and comprehensible.

Answer 7

In Java, the simplest way to programmatically manipulate XML documents is with JDOM. It has a simple API and supports XPath. If you are looking to extract information out of an xml document and put it in a database or a Web page, it's probably the easiest way you can do it in Java.

Answer 8

For extracting data from XML documents, XQuery may be better. See http://www.w3.org/TR/xquery/

Answer 9

I stopped using XSLT with java a few years ago.

Nowadays I use one of these alternatives:

- When transforming XML into other XML or doing checks on XML: XQuery using Bea Aqualogic or Saxon
- When transforming to a non-xml target: Freemarker template engine
- To do a simple XPath on XML: JDK 1.5 XPath validation.

Answer 10

Visual Basic offers an interesting alternative for XML manipulation. As a .NET programmer, I don't really see the need to use XSLT any more.

The End of XSLT for .NET Programmers?

Answer 11

From a programming standpoint, yes, there are probably many other tools that are better (I prefer plain old XMLDocument and XPath queries in C#).

But we use a fair amount of XSLT and it has proved to be a valuable tool to move logic out of the core application and push it out to business analysts. So basically, our app has an internal XML format. If a customer wants to send data from our app to another system that expects yet another XML format, the business analyst merely writes an XSLT to do the transformation before the data is sent. The big benefit is that there is no code that needs to be recompiled when our XSL changes.

This takes a big load off of our core programming group and lets them concentrate on app improvements and not get bogged down with one-off XML formatting tasks.

So I think the use case is important here. For situations like the one I describe I think XSLT is a very good fit.

XSLT seems to have fallen out of favor, but I think that is just a much a result of being misapplied/over-applied than an indictment of the technology.

Answer 12

We have been using Apache Velocity at my job for a few years now. We're a Java shop, so it works for us.

We used to use XSLT. We have documents (technically HTML pages) that we would need to transform by putting in values and conditionally showing/hiding sections, basically really simple stuff. That said the XSTL to do it was rather complex and a pretty big pain to maintain when changes were needed. Everything had to be perfectly valid XML, which meant cleaning up the documents others gave us by hand.

So we started using Velocity. Now each document is a velocity template. We pass the document and a few objects to Velocity and it generates things just the way we want. We can do non-trivial things through velocity (showing a section X times, or conditionally on something else) that would be a pain to do through simple search/replace stuff.

You may be able to make Velocity templates to make the output for you, which should simplify things.

Something to look into.

Answer 13

You could try LINQ, but it is also build on a functional programming base, so if you had problems understanding XSLT, chances are good you'll have similar problems trying to master LINQ.

This said, XSLT is a language which was designed from the very start with the main goal of being especially good at tree-processing (and an XML document is isomorphic to a tree as we well know).

Therefore, XSLT is one of the best possible programming languages to process XML. Add to this the existence of several popular libraries (EXSLT, FXSL, FunctX, ..., etc).

BTW, adding FXSL to XSLT 2.0 makes it a rather elegant, powerful and enjoyable functional programming language that has been proven to solve tasks in a large variety of problem areas -- from text processing, to the implementation of various math functions, to compiler-compiler systems, etc.

Answer 14

There are a million tools for manipulating XML that are better than XSLT. Focus on transforming XML, though, and the list of viable alternatives gets really short really fast.

Template semantics are essential to productive development of complex transformations, in my experience. I haven't seen anything in C# that comes close to being able to cleanly support templating. Even in Python, where you don't have the handcuffs of static typing to accompany the shackles of generating well-formed XML, the solution that emerges from miscegnation between ElementTree and Genshi is really not inarguably easier to understand than XSLT.

Another thing that swiftly becomes apparent when you start writing transformation logic with any complexity is that XPath is a fantastic tool for navigating XML. And when you use XPath in conjunction with (say) C# code that's manipulating the DOM, you're very likely to end up needing to use two completely different sets of semantics (XPath and C#) for doing what is essentially the same thing (testing nodes).

There's a lot about XSLT that's hard to swallow, but one of its great strengths is that it's a single, integrated, internally-consistent tool.

Answer 15

The most tricky thing to understand is the fact that you can do queries like in SQL and traverse the result. Often much easier than doing matching.

---

Edit: Also note that you could consider simply matching the root node and then generate your output in a traditional fashion. This makes you avoid having to do all the strange matches.

I saw a good example of how to do it with xhtml a while back. If there is interest, I can try to dig it up

Answer 16

You can give Scala a try:

• It has native xml support, with xpath like syntax.
• The transformer api works similair to xslt transformations.
• The for syntax is similair to XQuery flowr expressions.
• Is is a regular OO/functional language, so you're not stuck when things get to difficult to express in xslt.

Answer 17

If you are talking about the transformation of an XML document into something else, I've found nothing as powerful as XSLT. I agree with your remark about the learning curve, but in my opinion the effort is worth it.

XSLT has a number of advantages:

• fully declarative, a good match for XML documents that can be very exotic in structure
• some important business logic can be moved from code to templates
• templates are re-usable after a change of programming language, environment etc
• very, very powerful. this is where part of the initial hard to use experience stems from

If you are talking about creating XML, the template engine as described before is not that bad, although JDOM will handle that job perfectly as well.

JAXB and its relatives are useful if you want to perform other operations than a transformation in a program. But even that can be handled in XSLT by extensions, but the you would lose the portability of a style sheet from one language to another.