Why choose an XSL-transformation?

Question

For a current project the decision has to be made whether to use XML and an XSL-transformation to produce HTML or to directly use HTML-templates.

I'd be interested in arguments for or against the XSL-approach. I understand that in cases where you have to support many different layouts, an XSL-solution has a lot of advantages, but why would you choose it in those cases where you only have to support one target layout?

Edit: We're talking about Java here.

Answer 1

We use XSLT to generate html in our content management system and it works just fine.

Some hints: Don't try to generate all the page at once from one big hairy XML, you'll go insane. Use the HTML template (plain text/html file with styles, decorations and basic markup) with embedded markers (like, <!--MENU-->, <!--CONTENT-->), and replace markers with xslt-transformation of appropriate data.

Having said that, I doubt you really need xslt if you only going to have one layout, forever.

Answer 2

I've done significant development using XSLT and it has been both tremendously successful and a complete failure at two different sites.

A few thoughts before a conclusion:

• I don't think anyone would argue that XSLT is far more powerful than a template parsing engine, it's a functional language.

• Although it's not as widely adopted as most procedural languages, it's still a real language that's being used out there for actual projects, people can be hired already with knowledge of XSLT and it's a transferable skill for your current staff.

• XSLT has also been around for a while now, the implementations are mature, I'm sure this is the case for long running templating engines (like Velocity) but newer engines may be less robust.

• Whatever template language you decide on it's unlikely to be as well documented as XSLT. Check out any of the Michael Kay Programmer's reference series for an example on how to do a great reference book.

• Tool support is generally very good ... if you have a budget. XMLSpy and Stylus Studio have both been very useful for me in the past.

• XSLT is not only hard but, more importantly, different. Most people are not Computer Science graduates formally trained in functional programming. The majority of programmers will write XSLT in a procedural style which will not harness any power of the language and give you a maintenance headache.

• XSLT transforms can be slow and can take a lot of memory. You may have problems if you have a stylesheet with a large XML input.

I love XSLT but whether you should use it or not comes down to a few points:

Are you committed to XSLT? Do you have serious in-house expertise in XSLT? Are you prepared to get some?

Is your data in XML? Does it make sense in XML? Do you have someone in-house who loves your data enough to make sure it's well structured and there's always an appropriate schema?

Unless the answer to those questions is yes and you have complex data that requires a complex rendering process, I wouldn't consider using XSLT ... especially if there's no experience in the team. Bad XSLT is much, much, much worse than a bad template.

However, it can render complex data in a maintainable fashion which would be impossible using many of today's templating engines.

Answer 3

http://fishbowl.pastiche.org/2002/02/12/xslt_is_the_spawn_of_satan/

Answer 4

In contrast to HTML, there are a lot of XML tools available if you need to do parsing and processing of the templates in any way. So you should choose XML to get the benefits of using tools and libraries for XML.

However, that said, it may just be that XHTML fits your needs, since this gives you full support of XML tools and libraries while still being normal HTML which is correctly processed by modern web browsers. If you need to do post-processing of those later on, you can still apply XSLT to the XHTML data.

Answer 5

Going the XSL way will future-proof your application. Meaning, if you decide in the future to add more templates with different layouts you will be able capitalize on those advantages. In my current project we save off the XML used (in an XMLType or CLOB) and allow other applications to access the data and XSL templates to generate documents via a web service. This was an after thought of the original design that was super easy to implement due to our decision to use XML/XSL.

Answer 6

I think you need to examine what the source of your data will be. As mentioned by boris callens earlier, if the you are pulling from a database you will have to transform first to XML, then apply your transformations. Should the data source be RSS or the like, then XSLT is a natural choice.

XPATH and XSLT has a high learning curve and functional programming can be daunting to get your arms around. In time crunch this may not be the right choice.

For front end work JSON has a lighter payload, and is readily supported by jQuery and other Javascript libraries. You may want to consider JSON as the data protocol as the jQuery library is far more accessible to developers and the time to productivity with the framework is far less than with XSLT, embedded Javascript in tags, awful syntax and all the other minutia that come with XML/XPATH/XSLT on the front end.