XmlDocument is back

I had a foreboding of it. Dare Obasanjo:

For this reason we've reverted the XPathDocument to what it was in v1.1 while new functionality and perf improvements will be made to the XmlDocument. Similarly we will keep the new and improved XPathEditableNavigator XPathNavigator class which will be the API for programming against XML data sources where one wants to abstract away what the underlying store actually is.

That's a sharp turn! Strikeovered XPathEditableNavigator apparently means XPathDocument won't be editable and that's a main loss. Read-only XPathDocument has no chances to be any alternative to XmlDocument despite it's more effective, faster, more lightweight, XQuery-friendly etc.

They say developers love DOM. Hmmm, Java developers definitely don't, just look at numerous Java-and-developer-friendly DOM alternatives like JDOM, Dom4J, XOM etc. I remember my experience of processing XML using DOM in Java as a nightmare, I never had to write so dirty java code before and after that. Microsoft part of XML world is different - brilliant MSXML implementation is the only tree-based XML API for native Windows programming and ... it's brilliant. You see - the only and brilliant, that's a killer combination and that won't be so bad to have such one in .NET. Btw many don't realize MSXML actually extended DOM to make it at least usable, e.g. with "xml" property (InnerXml/OuterXml in XmlDocument) etc properties, which aren't actually W3C DOM). So the truth is developers love MSXML, not DOM. And they obviously love XmlDocument, because it's habitual and because it's is easier to use XmlDocument than XPathDocument even in areas where they compete. Try to select a value from namespaced XML to understand what I'm talking about. So XPathDocument is read-only and has clumsy API... No chances, be it even 10x faster.

The mismatch between the DOM data model and that of XPath meant that XPath queries or XSLT transformations over the XmlDocument would never be as fast as XPathDocument. Another reason we were doing this was that since the XmlDocument is not an interface based design there isn't a way for people who implement their own XML document-like classes to plug-in to our world.

So... Now we gonna be forced to work with slow unextendable XmlDocument once again just because of legacy and laziness of devs??? Too bad. I wish we had at an alternative. C# has unsafe, .NET has not only VB.NET, but Managed C++, see what I mean? There should always be some more effective alternative for those who aren't lazy to learn something new and up to rewriting some code to gain performance boost.

And there is another side - one size doesn't fit all. I doubt XmlDocument can be made radically faster and it's interesting to see how it will survive in XQuery era, whose data model differs from DOM even more than XPath 1.0's. So instead of focusing fully on reanimating XmlDocument I wish System.Xml devs to focus on developing several tools best optimized for different scenarios. I wish we had editable XPathDocument in .NET 2.0. Do you?