This post originated from an RSS feed registered with .NET Buzz by Scott Hanselman. Original Post: Oy...XPathDocument 2.0 changes moved BACK into XmlDocument! Feed Title: Scott Hanselman's ComputerZen.com Feed URL: http://radio-weblogs.com/0106747/rss.xml Feed Description: Scott Hanselman's ComputerZen.com is a .NET/WebServices/XML Weblog. I offer details of obscurities (internals of ASP.NET, WebServices, XML, etc) and best practices from real world scenarios. Latest .NET Buzz Posts Latest .NET Buzz Posts by Scott Hanselman Latest Posts From Scott Hanselman's ComputerZen.com

Ok, now I'm confused.  I just noticed this on Dare's blog and again Oleg's blog:

The problem was that the XPathDocument had a radically different programming model than the XmlDocument meaning that anyone who'd written code using the XmlDocument against our v1.0/v1.1 bits would have to radically rewrite their code to get performance improvements and new features...

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. We've shown the power of this model with examples such as the ObjectXPathNavigator and the DataSetNavigator.

So what are we saying here?

• XPathEditableNavigator functionality is being rolled into XPathNavigator, adding functionality to XPathNavigator and removing XPathEditableNavigator all together. Oleg infers that XPathDocument won't be editable. But it seems to me that Dare still called it new and improved and says later in Oleg's comments (emphasis mine):
• The XPathNavigator will be editable in Whidbey. However the XPathDocument will not be.
• XPathDocument in 2.0 will be the same as it was in 1.1, and the new perf improvements will be rolled into XmlDocument. This should speed up all the XSLT transformations people are doing against XmlDocuments today, rather than forcing them to use XPathDocument.

Is this correct?  Time to go re-write my chapter on XML! :)

UPDATE: I fat fingered the quote and reversed the meaning.  Dare cleared it up in the comments.

Dare sez:  "I said XPathDocument will still be read-only but the XPathNavigator interface will allow editing. This means I can use the XPathNavigator API to edit an XmlDocument but not an XPathDocument."