XSLT is used to transform one XML document into another. The canonical example is the transformation of a data-oriented XML document into a XHTML document formatted for reading in a browser. However, the evolution of dynamic Web sites has clearly favored procedural programming to get the data (ASP, PHP, etc.) and CSS as the formatting model. But I, like some others, originally thought that XSLT's great potential was as the linguage franca for transforming documents in a data-driven world. But here we are, on the eve of 2006 seven years after I first worked with XSL, and I am looking with utter dismay at a project that (potentially) involves the development of a custom XSLT transform.
The dismay comes from the idea of configuring my system for XSLT debugging, clearing a space beside my keyboard for Michael Kay's XSLT Programmers Reference (which is the only way to get through a major XSLT job), and plunging into the darkness. Or, I think to myself, Load the DOM, walk the tree, and write the nodes. A part of me finds this thought a betrayal -- XSLT solves this problem, darn it, and it's just a matter of figuring out the templates and then you write nice declarative transforms, as opposed to doing it in code, where you'll confuse transformation and declaration, mess up your responsibilities, shroud the transform in the fog of infrastructure, etc.
But when I've done major XSLT jobs before, I get the sense that I might as well have been delivering PROLOG source code -- it works (for now), it has theoretical advantages, if you immerse yourself in it it eventually clicks and makes sense, but... No one ever will. Expertise in XSLT? Hah!
I'm going to talk it over with my client, but I doubt that I will end up doing this in XSLT. It's a technology that's failed.