XSLT 1.0 defies the laws of physics – sucks AND blows simultaneously…

Holy crap, whoever came up with XSLT 1.0 must’ve really wanted me to suffer 🙂

I have spent the better part of a couple of weeks fighting with a simple piece of XSLT code to be able to generate some short, organized reports using the Microsoft Threat Analysis and Modelling tool (currently at v2.1.2).

It doesn’t help that the data model used by this tool has made a really poor choice in the way it classifies Threats:

  • The logical model would be to define an XPath like /ThreatModel/Threats/Threat[x], and then use an attribute or sub-element to assign the category of Threat
  • Instead, MS TAM v2.1.2 defines an XPath like this for each threat: /ThreatModel/Threats/$ThreatCategorys/Threats/$ThreatCategory
  • Thus, for a Confidentiality Threat, you get /ThreatModel/Threats/ConfidentialityThreats/Threats/ConfidentialityThreat

It certainly also doesn’t help that Microsoft has fallen behind all the other major XML engine vendors in implementing XSLT 2.0.  This article here indicates that not only did they wait to start any of the work until after the Recommendation was completed, but that they have NO planned ship vehicle or release date (despite the fact that XSLT 2.0 has been in the works for five years).

But really the fundamental problem that I (and about a million other people out there, over the last 7-8 years) am challenged by is the fact that you can’t pass what’s called an RTF (“Result Tree Fragment”) in an XPath 1.0 expression – the XSLT 1.0 standard just doesn’t allow dynamic evaluation of such an expression, AND they didn’t provide any reasonable way to actually get around the problem of RTFs.  It means that all the vendors providing engines to process XSL had to come up with their own extensions to handle this (e.g. [1], [2], [3]), and many people have also come up with creative (but horribly obtuse) ways to get around the problem.

So it goes – I’m stuck with (a) XSLT 1.0 & XPath 1.0 + proprietary “extension functions” [1], [2] in MSXML, because (b) the Microsoft TAM tool only uses the MSXML engine (which is fair – it’s gotta default to something).

What’s REALLY painful is learning that not only did I spend weeks banging my head against a wall learning some very obtuse and shouldn’t-be-necessary coding hacks to what in other languages are fairly trivial problems – but now I discover that it wasn’t even a question of RTFs at all, but rather that XSLT just ends up taking what I think is a reasonably well-thought-out design and dumping it on the floor:

http://groups.google.com/group/microsoft.public.xsl/browse_thread/thread/f3af4340991740e5

Oh, and how did the XSLT overlords solve this problem in XSLT 2.0?  The just eliminated the limitation on RTF in XPath expressions.  Done.  And done. 

Ugh – that’ll teach me to ever get lured into using a [functional?] programming language again.  Back to C# – that seems positively trivial by comparison…

SO: if you happen to have a masochistic streak in you, or you find that you absolutely must use XSLT 1.0 and not either XSLT 2.0 or System.xml.xsl, then (a) you have my sympathies and (b) here are some resources that I recommend you consult sooner than later:

Advertisements

One thought on “XSLT 1.0 defies the laws of physics – sucks AND blows simultaneously…

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s