Kind of off topic, but just want to chip in to say that XSLT is awesome. The average programmer can learn it quite quickly. For me, the "killer application" for XSLT is screen scraping HTML. If you want to aggregate data that is spread across a whole bunch of websites, it absolutely rocks. It is especially good if your organisation uses a SaaS that doesn't give you access to an API. Even if you have an API, it is often an order of magnitude easier to do what you need to do in XSLT. Which reminds me, I've been meaning to generate burn down charts for Trello for a long time now...
But for those who don't know the history, the vision was that XML would be this amazing interchange technology, and XSLT would be used to transform the XML as needed between and within apps, without needing real programmers.
For example, I know of one top-10 website circa 2004 that had their Java programmers producing only XML output. Then, XSLT specialists would transform that into HTML for rendering.
In theory, this provided a clear separation between back-end and front-end programmers. In practice, it was a giant clusterfuck, because any real work required coordinated changes at multiple levels. Although in theory the front-end work was independent, the reality was absurdly convoluted XSLT trying to turn not-very-good XML into something that rendered well on screen. Nobody sensible does this today.
At the time, XML/XSLT was expected to be central to a new, better way of making software. But now it's a weird niche thing, because although it was technologically cool, it was not actually better for 99% of use cases.
I just noticed your reply now. That's really interesting, because I don't think that this was ever what XSLT was for. However, now that you mention it, the company I was working for thought the exact same thing. I thought it was just they who were crazy. I guess the idea was more wide spread than I realised.
FWIW, there was a time when many people (embarrassingly, even myself) who thought that XML was a good way to represent data in a language agnostic way (these days, JSON fills that void -- there are even people trying to recreate SOAP and CORBA with JSON ;-) ). I won't go into the details of that, but even now I can probably make a pretty convincing argument that it's a good idea (which is why people are trying to recreate SOAP and CORBA with JSON ;-) ). But the point is that once you have data in XML, it's kind of a PITA to parse it (well, JSON is slightly better off there). If I just want a subset of the data, or I want to take bits of it and insert it into a different XML data set it's quite a lot of code to write. XSLT was for that.
But where we agree is that XML is not a great way to represent data (and, jokes aside, while JSON is much better it's also being overused). So without XML, there is no need for XSLT. But given that HTML can often be parsed as XML, it's still really useful for its intended purpose: to extract and transform data.
However I have seen one neat use in a previous job. We we dealing with a crappy API from a vendor. Crappy because it was a weird XML format, partially specified by a DTD but did unexpected things.
So we created an XSLT for the XML returned by their API. .NET allows you to generate classes from XSLT, so now we had a handy way to parse the data and process it. If we made any mistakes in the XSLT, just fix and regenerate the code. If the build breaks fix up any issues. The strong typing end to end meant we knew we had most of the cases covered.
