How to kill DOM

| 4 Comments | No TrackBacks

In the beginning Microsoft created the Microsoft.XMLDOM, known today as Msxml2.DOMDocument. And people like(d) it much. Then .NET happened and people were given XmlReader, XmlWriter, XmlDocument, XPathDocument, XPathNavigator and XmlDataDocument. Surprisingly most of us stuck to XmlDocument for no-matter-which scenario. Now we've been notified the Gods decided to kill XmlDocument and glorify XPathDocument instead. Be prepared...

Seriously, why XmlDocument is so overused? I think there are several reasons, from psychological to usability-related ones.

  1. For anybody with MSXML experience DOM is the obvious choice. DOM was the only data store in MSXML and the API. It's my understanding that MSXML SAX is almost only used by memory-anxious nerds. No surprise anybody with MSXML background coming to .NET takes XmlDocument with no any doubts. Such situation just cannot be changed quickly.
  2. XmlDocument is editable, XPathDocument is readonly. Unbeatable now, but System.Xml v2.0 gonna change it.
  3. XmlDocument API is simpler and more natural WRT MSXML background than XPathDocument's one in many common usage scenarios such as selecting a string value, especially it strikes the eyes when namespaces involved:
    XmlNamespaceManager nsmgr = new XmlNamespaceManager(doc.NameTable);
    nsmgr.AddNamespace("foo", "");
    string val = doc.SelectSingleNode("/foo:bar/text()", nsmgr).Value;
    XPathNavigator nav = doc.CreateNavigator();
    XPathExpression expr = nav.Compile("/foo:bar/text()");
    XmlNamespaceManager nsmgr = new XmlNamespaceManager(nav.NameTable);
    nsmgr.AddNamespace("foo", "");
    XPathNodeIterator ni = nav.Select(expr);
    string val = ni.Current.Value;
  4. XmlDocument exposes nodes, XPathDocument - cursor based API (but uses XPathNode's internally). Developers somehow like being able to select a node from document, dunno, may be it gives some secure non-virtual feelings to them?
  5. XmlDocument is closer to XML syntax level than XPathDocument. Developers like to work with XML declarations, entities, CDATA and OuterXml. They feel good when data store reflects XML syntax they see in Notepad. Don't ask me why.
  6. Developers don't care about perf. Sometimes they complain instead.

Well, we can do nothing with first and the last issues. System.Xml v2 will fix 2nd issue. Additionally XPathDocument will be improved with XSD types support, changes tracking, ability to validate, to reflect relational data via XmlAdapter etc. I'm sure they will make API more simple for ordinar developer too. In fact, System.Xml v2 gonna rock! So the only issue to cope with is community-wide DOM habit. How to kill it? I believe only with improving alternative APIs, leaving it out of XQuery-related future mainstream and evangelizing-evangelizing-evangelizing... Last task should be taken by XmlInsiders.

Btw, did you know that "dom" word means "home" in Russian?

Related Blog Posts

No TrackBacks

TrackBack URL:


Hehe, I didn't. It's close to english "dumb" probably.

did you know "dom" means "stupid" in dutch?

Yeah, I forgot this one.
But I don't see any problems here. "Kill" is only a metaphor actually and doesn't mean they want to deprecate and remove XmlDocument altogether. It will stay, exposing standard DOM API to support scenarios like you've described.
The goal is to make XPathDocument to be "obvious choice" XML store instead of XmlDocument.

Another reason people used the DOM is because it is a W3C spec, and is used on many different platforms. I can easily convert JScript that was used in IE's Element Behaviors to ECAMScript embedded in SVG as long as the JScript used the only the W3C DOM API, since both HTML and SVG both implement the DOM Spec. It is just as easy to convert the ECMAScript to C# and .Net, since the .Net framework implements the W3C DOM API (well mostly anyway).

Don't get me wrong, I'm tired of all the problems with the DOM and want to help convert people to XPathDocument, it is just good to know why so many people use the DOM.

DonXML Demsak

Leave a comment