For Matt Woodward: The Limitations of XML

Case 1: Simple, Non-Hierarchical Data
The first reason not to use XML is for simple - not hierarchical data it isn't necessary. If you only have property value pairs for a given config file, you can implement that using a simple = delimited, single pair per line format which does the job with less characters, increasing the readibility of the config data.

Here are two sample XML config files for property value pairs:

And here is what a config file would look like:

Property1=Value1
Property2=Value2
Property3=Value3
Property4=Value4

It allows you to fit more information on a page and requires less visual processing to grok. If your data is not hierarchical and you are confident that it will not become so (a big assumption, yet one that it valid in certain use cases) then XML is probably not the best concrete syntax to use.

Case 2: Scriptable configuration
Lets say that I want to describe my bean dependencies for a DI/IoC framework. And let's say that in my application, every business object has a Service class that depends on a DAO class. How would I express that in XML? Below is an example for three business objects.

Now imagine an application with 70 or 80 business objects and with 2-3 standard dependencies per business object. I'd show a code sample, but I'm just too lazy to type that much XML. I'd rather just write:

You can argue with whether this should be using a configuration bean to encapsulate the structure of the config data, but it is hard to argue against the need for looping and logic constructs for large configuration files. If you have any doubt, check out the discussions in the Java world which clearly highlight the strengths and weaknesses of XML for different use cases.

Conclusions
For safely and fully describing hierarchical data without using looping and conditional constructs, XML is the "least bad solution to the problem". Try replacing XML with something else and the most you can do without losing semantic distinctions is to replace the angle brackets with white space as in Python (and for some use cases even that isn't possible). You can remove the naming of each tag or attribute value, but then your document is much more brittle and dependent on remembering of conventions (second argument is the field length). This is actually OK for certain use cases where an expert user is looking for a terse syntax for describing a DSL that they work with frequently.

For instance, I prefer:

User extends BaseObject
@FirstName: Name: Optional
@LastName: Name: Optional

To:

It is clearly much more concise and I can work better with it (and can write a simple parser to translate it at compile time into XML if I want to use XPath or XSLT to work with it), but it does give up meaning and safety (in terms of redundancy) for conciseness.

XML is a great solution to many problems, but not the one true solution to all problems, so I hope I've clarified some of the use cases where it is a less appropriate solution. Matt?!