February 4, 2007

On embedding XSLT stylesheets into assemblies

I was writing about loading XSLT stylesheets embedded into assemblies (dll or exe) recently and Richard Quinn asked this very legitimate question:

But why oh why would anyone embed their XSLT in the assembly? The point is to separate design from logic. Even if the xslt does a non-presentational transform it _will_ be a pain to have to redeploy the assembly instead of just the stylesheet. Or not?


Well, having XSLT stylesheets externally no doubt has many benefits. But embedding XSLT stylesheets into deploy units (be it dll, exe or jar) is also done not without a reason. After all two the most often used in the wild XSLT stylesheets are embedded. I'm talking about res://msxml.dll/defaultss.xsl (technically not XSLT stylesheet) and chrome://global/content/xml/XMLPrettyPrint.xsl  - respectively Internet Explorer and Firefox XML pretty printers.

Embedding stylesheet doesn't necessarily mean coupling presentation and logic layers, in fact it has nothing to do with any application design issues. It's just deployment strategy and in that sense XSLT stylesheets aren't different from images or scripts.

Sure, when your XSLT file is just laying around you can tweak it without reinstalling application (sometimes even without restarting it). Sometimes that's useful and sometimes you don't want users to play with your stylesheet, because allowing that means:

  1. more code to write - you have to anticipate possible stylesheet changes, corruption or removal
  2. more testing
  3. potential security hole, because don't forget XSLT is a programming language and if that's not enough it can include extensions so that enables lots of interesting code injection scenarios for black hats. Sure with .NET 2.0 XSLT security options you can limit what XSLT stylesheet can perform, but then - it's your stylesheet and you are limiting yourself in the first place.

Again, sometimes deployment is easier if you don't have to bother about all that little files to be placed into the right place.

Some people embed, obfuscate and encrypt XSLT stylesheets trying to prevent reverse engineering. Well, apparently they do it for a reason too.

Performance is another interesting point. I think loading string resources should be a little bit faster than loading from the disk. Didn't test it though.

But the whole new era of XSLT embedding is going to start when XSLT finally becomes widely compilable into executable code. Next Visual Studio (codename Orcas, expected later this year) will include XSLTC.EXE - XSLT to MSIL compiler. That would add another benefit - save on XSLT compilation, which is time and resource hog.

If you do embed your XSLT stylesheets, I wonder what are your reasons?