XML: configuration or code?

Seems like there's a backlash against XML going on. Coding in XML is a code smell, and everyone is rethinking the overuse of XML in Spring configuration, for instance. Google Guice is the annotation-based IoC container, and now I see Spring 2.1 is doing the same.

I think there are two ways to look at the XML problem. One way is from the configuration management perspective - if you have a long process to build and deploy your software, you know how nice it can be to have a change be to configuration and not code. And maybe you'd deploy your software to many customers who configure it differently, if you're writing Tomcat for instance. There are surely some situations where the configuration of your app isn't simply key/value pairs, and XML is a nice way to structure your config files.

But of course this is abused, and Spring contexts are a good example. You don't expect that the customer is going to change the files, they're very long, and it's likely that a change in the app is going to require compiled changes as well as the XML changes. And they're really part of the code, wiring up objects in a specific way, such that changes to the context are likely to result in the app not working.

Annotations are the answer to this, it seems, since they put the configuration right there in the code. It's a more concise way to express the intent, the compiler catches your typos, and should make for better tool support. But, I have one problem with this - thinking about the Dozer bean mapping framework as an example. Here, we have two JavaBeans and the XML configuration describes how to map properties from one to the other. It seems anachronistic to give either Javabean knowledge of the other.

Maybe the better way to think about it is that XML should hold data. Facts, unchanging in time, with no logic, no tie to the classes themselves and certainly no relation to a certain runtime context. Sometimes the data is obvious, like the input to a DBUnit test. It could be some wire-protocol data, like a web service request used in SoapUI. Maybe sometimes it's configuration, like the servlet.xml file. Maybe it's even the dozer mapping file, describing how two JavaBeans' properties are related. Anything else, and yeah, XML is not a good place for it.