Are there any good reasons to use, learn, or recommend XSLT? [closed]

Question

I am a developer for the last 8 years. We used XSLT primarily to transform XML into HTML. We also used it for XML to XML transformation.

But we have replacement for everything now. HTML can be comfortably created through programming languages such as ASP.Net. XML can be read and manupulated in any standard highlevel languages. As programming in XSLT is a little complex, any one would prefer working on latest programming languages.

Now my question: Will XSLT be a significant choice in future, not considering the fact of maintaining already developed XSLT? Can I recommend new programmers to study XSLT?

Answer 1

There are some important cases where XSLT can be a good choice:

• ETL (Extract, Transform, Load) software can in some cases use XSLT. For example, it can be a good choice when both extracted data and data to load are in an XML format, and where transform may be changed without the need to recompile the application.

• Some applications which store data in XML use XSLT to present this data in a human-readable format¹. For example, Windows Live Messenger stores the trace of messages as XML, but when you open the history in WLM itself, it shows you a pretty table which in fact is HTML built through XSLT.

• Some developer-oriented or data-oriented websites may want to give an access to XML if the intent is to use the pages of the website programmatically². It is somehow nicer than to use HTML parsers, especially since HTML code can be changed at any moment.

• XSLT, when used in websites, allow strict separation between HTML and code-behind, which enables to hire a developer for code-behind and another developer for HTML/CSS stuff. See point 1 in my answer to another question.

Will XSLT be a significant choice in future? Well, this is not a significant choice today, and I doubt the usage of XSLT will increase over time. I ignore the reason of that, but many developers don't like XML and hate XSLT.

Can you recommend new programmers to study XSLT? Sure! Not only XSLT can be used in some circumstances when other approaches would be more difficult, but also XSLT has a very specific approach that other languages don't have.

---

^{¹ By this I mean XML is not really human-readable: if you ask a person who does not work in IT to read XML, he will be horrified.
² I know there are web services. But sometimes it's just easier and more straightforward, on every page, to construct a dynamic object, then to serialize it to XML, then, either transform it to HTML through XSLT or let the bot access the XML directly.}

Answer 2

Yes.

Let's take a good example: unit test reports in continuous integration. Most unit testing and code coverage programs simply output tons of unreadable XML. But with a few simple XSLTs, you can create a dozen useful reports from the same data. And other people can reuse those reports.

Now you could write these in whatever language the CI tool uses for plugins, but if you don't know that language (say, you're a .NET developer, using Jenkins) then there is no need to learn it. Simply use a plugin that already applies an XSLT to an XML file and write some useful XSLTs.

Answer 3

XSLT is pretty much dead because only a few enthusiasts still use it. However, there is no real alternative for it. If you focus only on a single use case, such as for example rendering of HTML pages from semantic documents, you find better tools. If you look for code generation template engines, again there is better tools. The same for document transformation.

But if you look for a tool that supports all these use cases pretty well on all platforms, then choices get very limited. If you already have an XML document and would have to transform it to something to be able to use your tool, you're probably better of just processing your data with XSLT (or XQuery).

Either way, you can learn XSLT in a matter of days, maybe weeks. It won't hurt you to make a first hand experience. Just give it a shot. It's at least worth the effort to store this kind of pattern (rule based transformations) in your head for later use. This alone justifies learning XSLT.

Answer 4

XSLT is not human-readable. The meta-information (the tags) take too much place over the real information (text, xpath requests). A good code should look like a documentation and this is fairly not the case of XSLT. It is rather a good persistence format for mapping tools.

A good transformation language should allow to preview the transformation result and view the transformation flow (IF, ELSE, FOR, WHILE) simultaneously. this is important for the maintainability. Regarding this aspect Velocity or GenearateXY are better than XSLT. GenerateXY is even a bit better since it separates the preview and the flow while with Velocity you would have to unfortunately break the preview indentation to provide a readable flow.

The only good point in XSLT is that it cares about modularity by using and even abusing of the "xsl:template" elements. The problem with this is that it is good for a data processing language (Java, C, ...) but very secondary for a presentation language.

Answer 5

There will always be choice and variety in programming languages, and the reasons why one gets chosen in preference to another are as much to do with familiarity and fashion as with objective criteria like functionality, productivity, and performance. No one can predict fashion, so no one can predict future trends in programming languages. But there are plenty of people who have got past the initial learning barriers for XSLT and find that it is an extremely productive tool for a very wide variety of tasks (possibly a wider variety than it was ever designed to tackle).

For many of the tasks I see XSLT being used for (and the tasks I use it for myself), writing Java or ASP code to do the job would be an appalling waste of your employer's budget. But perhaps not, if you happen to be good at writing Java and bad at writing XSLT.

Answer 6

XSLT's biggest failing is it inability (in any real implementation) to minimize the amount of the document that needs to be kept in memory at a time for efficient processing. Instead the whole document is read into some form of DOM representation and processing is done against that. If the document is very large, then so are the memory requirements. Yet many stylesheets clearly only need the current tag and a few others, e.g. the tag's ancestors, at any given time and thus could be processed with minimal memory and efficient streaming.

Yes, in terms of a language it's weird, but that's just a barrier to entry. If you know XSLT, it's often easier than the alternatives -- but if you will have large documents (or lots of documents being processed at once) the memory impact of XSLT often forces other, more time consuming alternatives.

Answer 7

Indeed

Something will probably supersede XSLT one day since it's a bit cumbersome to learn and use. However, there's currently no template/transformation language available afaik that is as flexible and "pure" in it's implementation.

XSL-T can be used for a few different purposes:

• You can "create" content in say HTML format from a data using a template
• You can convert from one xml format to another
• You can manipulate xml into another format, perhaps show a subset

Basically all these are the same thing however, the transformation of one XML data file to another. Now let's look at some different tools we could use instead of XSLT.

If we wanted to manipulate the content of say a XHTML page we could use regexp, but regexp is messy for structural stuff. It shines for manipulating strings but I wouldn't use it to create a table of contents for something or present it in a different layout.

Next is ASP.Net. We put our layout in our asp page and insert some code behind for the dynamic parts. Another alternative is to foregoe the layout part and generate everything from say a database and using C# creating our desired output.

The problem with the first approach is that it's clumsy to go from descriptive data to actual content. If you have some data file containing phone numbers which you want to present with headers for each letter, show a total nr of entries etc you'd have to have some of the layout in the layout file and some in the code you're generating. Another option is to use some form of web-grid put I find those to be pretty messy and suddenly you have to learn how the frigging grid works when all you wanted to do was to output some specific html given the data.

Going totally dynamic is certainly an option but that's rather clumsy as well. Even in the best case where you're using something like LINQ you'll have to intermingle programming code with output in a rather ugly way. Also there's no good way to properly handle unstructured recursive document-style content which html usually is.

With XSLT you simply can make a template for a certain tag, either just as is or in the context of it's parent so it's rendered differently if it for instance is parentet by something else.

A rather long rambling answer but yes, I think there's great value in a descriptive template language and XSLT is the best and most standardized one we got so far.

Answer 8

As a matter of fact, I think it is more efficient to use XSL than another language for presenting data. For example you can present an XML as a PDF using XSL-FO and you can control every inch, but if you work with RDLC (.NET) for example, you will see that is very difficult to present exactly what you want.

Even the evolution/correction is quite easy, as in XSL each element has its own template. I think that the extension of XSL is more important like XSLT and XSL-FO. That's why this language will still be used in the future (but i really hope that will be more stable and less complex).

Answer 9

I work for a Data Integration company and we use XSLT with our proprietary tools as a great solution involving XML to HTML/XML/Ascii.