As Joshua Allen mentioned in his blog our team recently had a WinFX Review. This is basically a design review with a number of top architects from across the .NET Framework to ensure that the API you are building is consistent with the design guidelines for an API that will be shipping in the next version of Windows (i.e. LongHorn). We got a lot of good feedback which we are in the process of responding to and has caused a few design changes. The good news is that we've come up with a story for XPathNavigator2, XPathEditor  and XPathDocument2 that most people who've heard are happy with.

After the review we were pinged by Anders Hejlsberg who missed the original design review and asked if we could do a mini-review with just him. He gave lots of good feedback, questioned some of our scenarios and was quite amiable. I think he was mostly satisfied with the design decisions we'd made but thought we could do more in making processing XML dead easy as opposed the current situation where the developer needs to know a bit too much about XML and our programming model.  He also talked about the tradeoffs of going to a cursor based model (XPathNavigator2/XPathEditor) from a tree based model (XmlNode) and the disconnects developers may feel once they make the shift. I suspect it will be similar to the disconnect developers initially felt when moving from MSXML & Java which had a push-based model (SAX) for processing XML in a streaming fashion to the .NET Framework which uses a pull-based model (XmlReader). At first it was unfamiliar but once they started using it and saw the benefits they preferred it to the old way.

That said we do need to think some more about how to better benefit the “XML as config file format AKA CSV on steroids” demographic. A large number of developers just see XML as nothing more than a format for configuration and log files in which case a lot of the cruft of XML is meaningless to them such as entities, processing instructions and CDATA sections.