As for W3C, why waste my time? I don't think that CSV is an appropriate solution for their problems. It is a good one for interchanging a lot of the data that exists within the bond world, which is why there are standard formats there which have been used for years specifying CSV formatted data. They are here. They work. People use them.

And when it comes to management and hype, sometimes that is life. Personally I prefer it when developers are free to choose the most cost-effective tools for what they are doing. (For one thing PHB heavy companies don't do so well. And companies that always seek to follow the herd tend to find a lot of nasty cliffs. Big companies have enough intertia to survive most such cliffs, small ones do not. Either way, they aren't fun for the developers who go over them.) If that means XML, that means XML. If it means CSV, then that means CSV.

When it comes to tabular data I prefer CSV for several reasons. The first is that it is easier to see that it is tabular data at a glance. The second is that I prefer getting a 2 MB file to a 10 MB file. The third is that it takes a lot less work to set up a CSV format than it does to set up a DTD, etc. The fourth is that most people who work with tabular data already have more tools for CSV than XML. (Try any spreadsheet application.)

For non-tabular data, well CSV is not appropriate for that. Use the right tool for the job. As for when XML makes sense for that, I don't have much of an opinion. I haven't had to solve that problem extensively. Certainly it was originally designed for that problem space, and the sheer effort that has gone into XML undoubtably has resulted in some effective tools for some problems. The hype has also definitely resulted in it being used for problems where it doesn't make sense. I just don't know where the boundaries are.

You'll have to admit that XML is a very good exchange standard: it allows you to specify the encoding of information, it get rid of line ending problems, it is reasonably sef-documented and quite human legible. If all else fails you can always fire up vi and figure out what's in the file you just received.

I quite agree. I'm no standards expert, but I think one of the clearest benefits of XML lies in a field wider than just code. With more and more dynamic community-based sites popping up by the day, and you average Joe wanting to make the stuff he writes on them look cool, the general public is becoming much more familiar with HTML. And, "XML looks just like HTML".

The angle brackets of HTML looked very odd to me when I first saw them, and I'm sure they still do to anyone new to that stuff. But as the new generation takes up computers, HTML will begin to be understood by people, and I think eventually XML or a derivative of it will become the language for all code-related human-maintained files. By this, I mean that configuration files for your Perl programs will probably be written in XML, as that way everyone will understand them. None of all this silly var: value syntax that has to be relearned for every program that works slightly differently. Feel free to disagree, but I think that's a good thing. (/me shudders when he thinks of Esperanto, and hopes the same doesn't apply here...)

I speak not as a devotee of XML; I'm still deciding on my module of choice, my familiarity with XML::Parser amounts to a brief look over the tutorial here, and reading the standard gave me a brain-ache. I certainly don't force people into using it. But I am excited about getting an oppurtunity to use it. I admit, tilly, that none have come up yet, but if/when one does I'll jump at the chance.