XML! The answer to every problem the world has!
Almost any technology you can invent is going to be used in ways you won't expect. This holds true of most of the things you write, and it's part of the reason I try to tell people to get their APIs as complete and correct as possible before the first release, so that it's easier for people to do interesting and unexpected things with your code.
XML on the other hand seems to buck this trend.
XML was created to provide a neutral and verifiable format for structured data, so that the biggest problems in doing "document/data interchange" were solved for a (large) one time cost in development resources.
A bunch of people have put in a ton of work to create code that burns a whole bunch of CPU time to solve some very nasty problems, so you can concentrate on the specifics of a situation.
The expense of XML means that unless you are doing document interchange (moving files and data between disparate systems written in different languages or on different backends) it can be REALLY hard to justify all that expense. A lot of the time you'd probably do better with YAML, JSON or even Config::Tiny-derived data storage.
Some of the worst offenders are config files that people create in XML just because it's fashionable. You really don't need it, unless you plan to do document interchange of those very config files (for example the deploy configs for Java web applications).
I arrived a while ago at what I think is good measure of whether you really need XML or not.
"If you don't need a Schema, you don't need XML"
That is, the situations in which it's worth the cost of XML at all are most often those in which you need the power of the validation provided by Schemas, mainly due to trust boundaries.
For example, when swapping documents or data with customers, or when you need to move data between code written by different people. Although it's nice to have trust between you and clients or other coders, what is much better is to be able to work with other people's systems and code without having to trust them at all. Mostly this is protection against miscommunication, stupidity and accidents, rather than outright maliciousness, but there's a lot of all four going round.
I find things like XSLT, which was envisaged for doing tasks where you'd only have the difficulties of writing the XSLT once (like changing NikeShoeML into ChineseFactoryML) a gross waste when employed as a HTML templating mechanism or similar. (although I'm sure there's a subset of cases it's genuinely needed)
As a result, so far in my entire career I've only needed to deploy XML "in anger" once while doing perl consulting work. It's a big sophisticated application doing some wonderous things I try to avoid talking about except verbally or in un-Google'd space.
The client's C-based system (about which I know nothing else) fires XML batch job requests at my Perl server, which processes them over a few minutes or a few hours, and returns the results and errors as another XML document.
So XML for me is a sign of doing Something Big.
I've just deployed an initial development release of my first ever XML CPAN module. It's the beginning of World Domination Plan #6.
Writing a SAX Parser was even more pleasant than it was the first time. I'm really getting more and more impressed with Matt Sergeant's XML::SAX every time I use it. And all I need now is to find a little more time (hopefully at YAPC::AU) to complete the API (which in this case also means the XML Schema) and I'll be ready to unveil plan #6 to the world
It's going to kick ass! I promise
(once I work out how the hell to install an