Question

What are the principles and patterns that go into writing effective XSLT?

When I say ‘effective’ I mean that it is

1. Well-structured and readable
2. Simple, concise
3. Efficient (i.e. has good performance)

In short, I’m looking for the best practices for XSLT.

I’ve already seen the question regarding efficiency, but efficient code loses its value if you can’t understand what it’s doing.

Answer 1

I think that a good way to answer this question would to approach it from the other side. What practices make XSLT ineffective, and why?

Some of the things that I’ve seen that result in ineffective XSLT:

1. Overuse of for-each. Everyone’s said it; I’m saying it again. I find that for-each is often a sign of the developer trying to employ traditional programming techniques in a declarative language.

2. Underutilizing XPath. A lot of bad XSLT I’ve seen exists purely because the developer didn’t understand predicates, axis specifiers, position(), and current(), and so he implemented logic using XSLT constructs instead.

3. Underutilizing metadata. You can sometimes eliminate an enormous amount of XSLT by providing your transform with metadata.

4. Underutilizing pre-processing. If, for instance, an XML document contains data that has to be parsed using XSLT string manipulation, it’s often much simpler to do all of the parsing outside of XSLT and either add the parsed results to the XML or pass the parsed results as an argument to the transform. I’ve seen some remarkably unmaintainable XSLT implementing business logic that would be trivial to implement in C# or Python.

The biggest problem that I’m running into in my own XSLT world (I have several 3,000+ line transforms that I’m maintaining) is dead code. I’m certain that there are templates in my transforms that will never be used again, because the conditions they’re testing for will never arise again. There’s no way to determine programmatically if something like <xsl:template match='SomeField[contains(., 'some value')]> is alive or dead, because it’s contingent on something that metadata can’t tell you.