If you believe all you read, you'd think you can use XML for anything. Well, you can. Just like ASCII (and exactly like 0s and 1s), most any value can be represented in some fashion using the XML standard.

The question is not what XML can be used for but when you can best use XML. Luckily, the answer is simple.

Use/expose XML whenever someone may need to access data from your application who will know absolutely nothing about the way you've programmed your application.

Alternately, this reads:

Use/expose XML whenever someone may need to access data from your application and you never intend to work jointly on the project.

By this I mean the *internals* of your application. Naturally, you do need to expose a few bits, like the functions via a discovery file or the innards of your data with an an XML schema. But if you're using Objective-C with a backend of File Maker (or something worse that's not even ODBC compliant), you're not going to appeal to your standard VB6/Jet Engine programmer, and vice versa. Rather than getting up to speed on your techs, you both simply "agree" to understand XML.

There are other times you might use XML, of course, but basically they boil down to the same situation. Got a Java-based system that needs to talk to .NET? Essentially you're at the same place. Your programmers don't know anything about the way the other program is written, b/c they can't write in a language that can tweak the other's innards (okay, I'm oversimplifiying a bit).

Does your system written in Java have an ODBC-compliant backend? There's your Rosetta Stone! Now we can use ADO.NET to talk to an app written in C#. Vice versa? Use the JDBC-ODBC bridge or a a native JDBC driver (Microsoft even provides a native driver for SQL Server 2000, no less) and get Java dealing directly with recordsets.

Are you providing news feeds that you'd like anybody to be able to quickly access without them ever bothering you to figure out how, like Slashdot does? Use XML, the universal standard for creating Rosetta Stones when you can't find a single good standardized data-transfer technology in your joint development plans. (I feel I should point out that you don't have joint development plans with Slashdot by definition. They don't want to hear from you, so XML is the way to go.)

Do you have a configuration file for a small application that your company wrote in a year that no other application will ever need to read? Write it using a text file. Really. XML might seem cool, and certainly it *can* do the job, but save yourself the time, the overhead, and the testing; use a tool more suited for the job. If another application needs to read this information later, they can get the text file format from you, look at your code, or, if necessary, you can then refactor to use SQL Server, Postgresql, or even XML.

XML is the Rosetta Stone of last resort. Otherwise it's an over-engineered ASCII replacement.