>>11
You can read it in a text editor, no MACHINE CODE involved
Good if you actually have to read it; if it's going to be some sort of protocol to store data or exchange it with other applications, you don't need to waste space/time on this. Furthermore, XML is not particularly easy to read and write with a text editor; there are other formats which are simpler to work with for this matter.
PHP: domxml_open_file() <- native support for XML
Okay, but see if parse_ini_file() will do, too. And a note on "native support": you still have to know your stuff. Having an XML library isn't any better than having a general-purpose parser (in fact, it's far more restrictive). You still have to give a meaning to all those tags. It never means you can magically talk to anyone.
Python: xml.sax.parse() <- native support for XML
Perl: CPAN XML <- lots of CPAN modules for Perl
Python and Perl have native support for almost anything.
C++: xmllib + lots more.
C: Flex+Bison = "native support" for anything. Similar parsers available for Python, Perl, and more.
The four previous points also mean that it's very good for sharing data between software and the web, and so on.
Software and the web - what does "the web" mean? More software? Not yet written? Then use a binary format.
Being able to read your input/output data makes debugging a whole lot easier.
I can read any data with a hex editor or a sniffer, and it's not an order of magnitude harder to work with once you're used to it.
Being able to WRITE "serialized" data for your program allows you to test the program in all sorts of ways that might not be possible when you have to rely on other software to create that data for you.
Needing to write it makes text formats easier to work with, but a more binary format using a binary-safe editor works too, and again, XML is not the only one, nor the easiest or more convenient text format.