|Perl: the Markov chain saw|
Using XML for broad, general databases doesn't make much sense, no. It's just another wheel being reinvented - in a fairly awkward way, too.
I can see it helping in narrow contexts, however. If your application only needs to store a particular kind of data, then a full-tilt relational database might be a little bit of overkill. The FAQ generation that was mentioned before is a perfect example. On my own, I've used XML to store configuration details for a meta-search tool, news items for a small site, and even a simple guestbook CGI.
I prefer XML over CSV because of structure issues. I am a geek of Very Small Brain, and I like it when my data storage is self-documenting. Of course I document my own CSV files every time - it would be wrong not to :-) But there have been too many times where I examine a client's data files and find:
You can still find bad or no documentation in an XML file, but generally I've had good luck coming across clearly named tags. Even in the worst cases, I've been able to figure out quite a bit from the structure of the markup. (I'm not sure what 'DO4' is, but it doesn't have anything to do with the address, because that's way over in this other element.)
Of course, if your project has a lot of data with intricate relations that needs to scale way waay up, then you're back to relational databases. XML is convenient for data storage, yes, but it is not the best tool in all cases.
So yeah - XML as a database for small, very specific sets makes sense to me. And yes - the world is nutz.
"All you need is ignorance and confidence; then success is sure."-- Mark Twain