XSLT is *very* helpful when it comes to business-to-business data exchange. Of course, this assumes that both ends of the transaction are using a text based format as the interchange medium. When it comes to that, it's a dream. Trust me, I've had to hook up several b2b transports for the company I work at now, and XSLT makes the job a helluva lot easier. It becomes nearly trivial to transform data from one type to another.

Another example is something like blogging engines. There are actual engines out there that use XML as their storage medium. Why? Because of transforms. My website actually uses XML as the storage medium (not truly by choice though, simply because I'm too lazy to get proper hosting). The beauty of having all your data in XML format is that I have one XML format that serializes extremely easy into my domain objects for my publishing application. And then to generate both the home page, the article page, and the RSS feed, all I do is run that one native XML document through three different stylesheets and boom, all pages needing changing are generated for me.

Remember, XSLT isn't only for XML -> XML. You can have XML -> XML, XML -> HTML, XML -> XHTML, XML -> CSV, etc. When you are generating a lot of destination files from one source XML file, XSLT files are a lot easier to maintain than having to go in and change DOM code in order to navigate the XML document differently. XSLT becomes even more powerful when you start realizing the potential of XPath.

Wow, sorry to post such a long comment! I would just hate to see you turn your back on XSLT because you don't see the value now. There is always the right tool for a job. The difficult part is knowing the right tool and knowing whether it's the right job.

p.s. Obviously I'm an XML junkie :P.

As I hope is evident, I don't turn my back on a technology until I have at least tried it and know a bit about it. (Exceptions apply to stuff written by companies whose business methods I disagree with.) So I am reading up on XSLT to try and understand it better, and to have that extra tool in my toolbox should it ever become useful to me.

I've done business-to-business XML exchange before, but since either we or they had control of the format, no transformation was ever needed. Maybe if you had strict requirements at your end and yet had to use an existing XML document that couldn't change to suit your requirements, it might come in useful. Generally though I'd think it would be simple enough to cherry-pick whatever element/attributes you need as you go through it. I am sure there are cases there where writing a set of XSLT transformations might be simpler than doing the check in your native code, but they seem rare to me. Not to the point of making XSLT useless, but making it a bit of a niche tool - in direct contrast to the way it tends to be described (in conjunction with XML).

I don't see the benefit in using XML for the blogging engine you describe. How is that any better than using an SQL database and your choice of scripting language?

I think my main objection comes down to this: XSLT is only really useful when XML is your native data storage format, yet I can see very few cases where I'd actually want to use XML in that way. The cases where I do use XML that way tend to be as direct load/save formats, where I don't need any transformation.

I use XSLT a lot; it has to be said that I don't feel as if it's a technology looking for a use. We've spoken before about my use of it in web pages, so I won't bore you with that again.

A project I'm working on here at work uses it for it's reports. The program analyses a load of data based on a user-specified template and the program outputs the analysis of this information. As it stands, there's three groups of people who want the data, those who'd like a nice HTML report of the information, those that want just a plain text dump with minimal formatting and those that want CSVs of the figures for later analysis.

The traditional way of doing this would be to create separate report generator classes (or just functions) to take the inputs of the data and generate the relevant output. However, this application is one that needs to be shipped quickly and as such is likely to be needing tweaks to it whilst it's in use. Knowing the nature of this company, people will want the reports changing to fit their department or needs so it makes very little sense to keep the report engines as an integral part of the application.

My solution is that the report engine generates an XML file that contains all of the report sections and data for outputting. The user can then choose an XSLT file that correctly formats the report according to their needs. If the layout isn't how you want it, tweak the XSL - simple. It also allows me to add new report formats without touching a single line of code in the application, all it cares about is that it throws an XML file to a transformation and saves it.

XML/XSLT is ideal for separating content and design from code. The scripting solutions around will normally intertwine design with code, which is fine if the design of a system output is fixed and will be unlikely to change. However, if it is likely to change or is even undefined, then XSLT is your solution. It will only be of benefit if, as I said, content, code and design are considered separate streams. When these merge in anyway the uses for XSLT starts to deminish.

I suppose the key there is that it's used as a filtering and rearranging technology. Filtering I find I can do equally well with whatever language is used at one or the other end of the data pipeline. One area where I can see XSLT beating everything else though is the extensive rearrangement of selected elements, which would be tedious to do in TinyXML or similar.

I think I should admit to having made the original journal entry a bit of an exaggeration. I don't think XML/XSLT is useless, by any means. I don't have the TinyXML link in my signature for nothing. ;) I am just fed up of people acting as if it's going to be the technology that saves programming. The idea that people think it should be a native data type in mainstream programming languages (when concepts such as decimal numbers, rational numbers, and unicode strings often are not) just seems absurd to me.