XmlDocument is back

| 6 Comments | 3 TrackBacks

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?

3 TrackBacks

TrackBack URL: http://www.tkachenko.com/cgi-bin/mt-tb.cgi/284

This sucks. I want editable XPathDocument.... Read More

Aaron asks if we believe in Contract-First. I sure do. BUT, he nailed it right on the head: It's very... Read More

TITLE: More Information on the XPathDocument/XmlDocument Change in Whidbey beta 2 URL: http://blogs.msdn.com/dareobasanjo/archive/2004/09/03/225070.aspx IP: BLOG NAME: Dare Obasanjo's WebLog DATE: 09/03/2004 07:48:38 AM Read More


So it's editable XPathNavigator with read-only XPathDocument. Hmm.
Well, it's definitely a step in right direction. Too small, but at least now it's possible to develop Mvp.Xml.EditableXPathDocument without inventing proprietary update API.

So they cut WinFS out of LongHorn and some of Avalon(?) as well and basically decoupling all 3 pillars of the next gen platform from Windows so that developers don't have to change their existing code to run on longhorn. I guess, MSFT is siding with the Chen Camp...

The XPathNavigator will be editable in Whidbey. However the XPathDocument will not be.

Lets build our own like Don said. That was a bad decision by them. Devs like DOM because they don't know anything else. Evangilism on the topic would rally the support needed.

Sounds like a perfect opportunity for the Mvp.Xml project!

Do it ourselves, or get MS to release the code as open source. The best of both worlds, backward compatibility and something or the cutting edge folks that need the performance.


I do.

I already have an XpathNavigator over a relational content model, and I was waiting like crazy to making it Editable.

Leave a comment