Wow, I never thought I'd see someone say that. I found it to be an endless nightmare when I had to use it. (We thought t would be really cool to store links and other stuff in XML and then transform that into our ASP.NET pages, so we could change the XML file without changing the website. It got complicated over time.)
The point about the syntax is a good one, but I don't like the idea that people should just equivalently like any syntax that expresses the same basic ideas.
I can't say why exactly but something just feels fundamentally wrong with writing code in XML. I felt the same way when I had to write MSBuild scripts, which are XML. I guess it could be trying to do imperative things in a declarative language, but that doesn't seem to be a problem for Lispers.
I used to use it in the browser (IE with MSXML, back in the early/middle part of the last decade) for web apps. XML from the server, XSLT in the browser to generate the UI. You could re-sort, filter, drill-down, etc. all without ever hitting the server again. Just different transforms on the same data. I loved it. Never felt so productive. Rich responsive apps years before JSON and Jquery and all the subsequent JS frameworks started gaining traction.
Syntax is verbose, but felt that the power was worth it. Never found a declarative, functional way to do the same kind of transforms on JSON data, but I'm sure it must exist by now.
I need to agree. Using XSLT to write a XML -> HTML website is not a good idea - at least when a bunch of developers maintain it over time.
From the ground up, I admit I like XSLT. But: maintaining large sites that inherit templates (call-templates and apply-templates) and style through <xsl:include/> and <xsl:import/> over lots of files tends to become a template mess. After a while only the experienced devs are able to maintain the templates.
Then, it's a functional language, where lots of things are overly complicated to do; you can do just everything, but that doesn't mean you should.
I work together with a bunch of developers on a website that renders its HTML output with XSLT. What you address is architecture.
What we basically did is we have one XSL file for each "element". Elements are: button, image, headline, etc. Each of those elements inputs "our own" XML syntax with wisely chosen defaults (some HTML attributes like class,id,style get just passed through) and outputs Twitter Bootstrap HTML. Writing responsive websites in our framework is extremely easy. So each element has a XSL file where the magic happens, an XML file with documentation and tests and additional files like scass/css/js files with the same name. Accessing them is extremely easy when you use something like Sublime Text (what we all do).
All those different templates get written into just one XSL file automatically with the help of node.js' gulp.
The website gets delivered in Apache Cocoon which has a pipeline concept similar to gulp. Once a page got rendered, it is cached until the next update (except for pages with dynamic content of course).
The whole frameworks documentation is basically a website written in this framework with automated tests.
We use XSLT 1.0 + EXSLT and have written around 30 (EXSLT) functions to make sure everything works like we expect.
I concur, long time ago I was forced to use XSLT in a business interoperability setting and it was a nightmare when I needed to do any advanced (=competitive) stuff done; it ended up almost as incomprehensible as a multi-stage map-reduce algorithm.
Now for my own e-commerce ETL system I actually had to do a transformation engine encompassing JSON, XML, SQL and NoSQL in Python and rather decided to stick with the KISS principle, allowing declarative stuff for basic simple operations such as multi-key joins and offloading advanced stuff directly to customizable Python scripts.
The point about the syntax is a good one, but I don't like the idea that people should just equivalently like any syntax that expresses the same basic ideas.
I can't say why exactly but something just feels fundamentally wrong with writing code in XML. I felt the same way when I had to write MSBuild scripts, which are XML. I guess it could be trying to do imperative things in a declarative language, but that doesn't seem to be a problem for Lispers.