you could just as easily write external software to validate that CVS as well

Not quite. First if you are dealing with sloppy providers they might not include the CVS headers and then how are you going to know which field is missing when that happens?

Then really, DTDs are written using a language designed for language description. You can't really compare it with a programing language, more with the table description part of SQL, or with lex+yacc. For a concrete evidence You can have a look at the IEEE Standards DTD (be warned though, loading the DTD crashes my Mozilla) and tell me how easy it would be to write a Perl program that would parse and validate data tagged according to that DTD (it's SGML, but XML is just the same). I know I'd rather write the DTD and let any parser do the job!

Makeshifts last the longest.

One method call, validate().

And what, in the absence of a DTD, is the XML validated against? Simply that the brackets are all matched and it's syntactically valid? That's the same level of "validation" that you get by counting the commas in each row of a CSV file. Neither one tells you whether the data is formatted appropriately for your intended use.

By all means, if you are more at ease with CSV use CSV. It might be really well-suited to what you are doing and you might not need anything else. I will also be the first to admit that XML is no silver bullet. If people want to throw garbage at you they can throw XML garbage just as well as they would send you useless CSV.

OTOH in the real world XML takes care of encodings (ever received UTF-8 data when you were expecting "regular" latin1?), most people feel that it is more self-documented than CSV. It is also more flexible: it can model more than just tabular data and it is relatively easy to write XML code that can survive moderate changes in the input format (such as new element types being added) without upgrading. The tools are also pretty good, at least on par with the tools you can find for CSV.

In short there is really no need to change all of your tools and all of your processes just to become buzzword-compliant. I don't think any one is advocating this BTW. So stick to CSV if you want to.

I just want to point out that there is really no need to try to convince people that CSV is better than XML. XML is just a rather powerful and well thought-out low-level standard for documents and data interchange. I hope you don't spend your days writing low-level CSV code and that the main logic of your applications is a little bit more interesting ;--) So really whether the underlying format of the data is CSV or XML is not that important. Choose the one you are comfortable with, provided it's powerful enough to work now and in the future.

You know, I rather like ASCII myself, but I don't really try to convince people who use Unicode that they stuff is useless, and I must admit that sometimes 8 bits just don't cut it and I use Unicode.