You've probably read a lot by now about the tension between the OO purist view of the world and the XML purist view of the world. You might also have picked up that I personally find myself more at the XML end of the spectrum, due in no small part to the influence of Tim Ewald.
One day not too long ago, Tim rang me up to tell me about a revelation he had had. He used to hate XmlSerializer because it embodies the fallacy that there's an isomorphism between objects and XML. But he explained to me that if you looked at it in a different way - simply as a convenient mechanism for populating a set of variables - that it wasn't so bad. The idea being that in order to code against the XML, you're going to have to find a way to pull the data out and get it into variables. XPath is one way to do that, but so is XmlSerializer. I generally followed his argument at the time, but it didn't really sink in until recently.
I was trying to rewrite some of the configuration code I'd done for one of my clients. The issue was that we have a whole bunch of web projects, and having to make changes in 17 different web.config files was annoying. So I wanted to set it up so we could simply point to a single config file in a well-known directory.
I started off using a modified version of my XmlSerializer configuration section handler. But as I was looking at it, I realized that there was a better way. As it stands, the section handler expected XML in the config file that looks like this:
<configuration>
<!-- configSections element goes here -->
<MyStuff type="SomeNamespace.MyStuff, CraigsConfig">
<Foo>1.234</Foo>