I couldn’t really decide on a title for this post. Originally it was going to be “A Guide to the XML Parser API Wars”, but I thought that might be a little too negative. I was looking for something that would catch the average reader’s eye, but also put a positive spin on a hotly debated topic. If you have read this far, then it worked, and don’t stop reading until the end of this post, since (IMHO) this is a very important topic (well, for .Net developers, and others interested in XML).
I know I haven’t been posting as much high quality stuff over recent weeks, but it is due to time constraints (buying another house will do that to you), and not for a lack of interest. Plus, there’s a ton of behind the scenes stuff going on, and the gory details would be boring, but the final result will (hopefully) blow you away.
Back to the original topic, waking up from a DOM induced coma, what do I really mean with this statement? Well, as all good XML developers know, there are 2 main (could also be called “standard”) methods to parse your XML: using the DOM, which loads the whole document tree into memory and is (relatively) easy to use, or via SAX, which is extremely fast, doesn’t have a large memory footprint, but requires a bit of (repetitive) coding techniques. Since the majority of .Net (and previously VB/MSXML) developers didn’t need the performance of SAX, we typically used the DOM method to parse XML in our applications. When Microsoft rolled out .Net, they didn’t include a SAX parser for .Net, but something just a fast (and just as complicated to code against) called the XmlReader (which is basically the pull version equivalent of the push style SAX parser), and .Net developers still had basically two ways to parse XML, and most developers still used the DOM. If you want to parse some XML, you used the DOM. If you had to worry about memory or performance, you used one of the XmlReaders. Life was good, and as developers we fell into a DOM induced coma.
But then. slowly (very slowly) word got out about this new fangled XPathNavigator method for parsing XML in .Net. It was a cursor model style of parsing XML, that although it still had to load the entire XML document into memory, was a much faster parsing method than the DOM, and could be used in a lot of cases where the DOM was being used. The down side was that it was read only, but hey, so is the XmlReader, and XPathNavigator was easier to use that an XmlReader. Slowly, a few developers started to wake up, and start using the XPathNavigator instead of the DOM. Then, at the 2003 PDC, it was announced that the next version of .Net was going to contain an updateable XPathNavigator, and the folks that woke up started to chant “The DOM is dead”. But still, the majority slept.
The developers who did wake up to the news of new XML parsing methods started to communicate with others that had awaken from their slumber, and started to share stories, and began dreaming of new ways to parse XML. Dare Obasanjo wrote an article in the October 2003 XML Journal, Can One Size Fit All – Exploring the Possibility of One API for XML Processing which spoke about the different ways to parse XML, and maybe, just maybe we can create one base API for processing XML, and then build others on top of that. Then others started to play with newer XML processing models. Daniel Cazzulino started prototyping something he called Xml Streaming Events which gave the performance of XmlReader (or SAX) but still let you use XPath like statements. Oleg Tkachenko explained his ForwardXPathNavigator idea, which is similar to XPathNavigator (and Daniel’s XSE), but only allows for Forward only XPath statements. Finally, it came back full circle to Dare, when he mentioned Arpan Desai’s (another MS Program Manager) Introduction to Sequential XPath Paper (from way back in May of 2001).
But, Dare dropped a bomb that should eventually wake the rest from the DOM induced Coma, the XPathReader for processing XML. It is very similar to some classes that are currently only available in Biztalk 2004 (which Oleg did mention in this post), and combines the best of Daniel’s and Oleg’s ideas, along with Arpan’s Sequential XPath (aka SXPath). The very cool thing is that it isn’t part of the .Net framework, but will be open source, so we will not have to wait until Whidbey (or whatever release it may have made it into) before we can use it. The down side is that Dare hasn’t release it yet, but will release it as part of the MSDN Xml Dev Center rollout. Why do I think this is so cool? Well it looks like .Net finally hit critical mass. The developer community is large enough, and educated enough, to be able to dramatically impact one of the core tenets of .Net, XML. It is something that the folks in Microsoft that believed in .Net way back in the beginning should be proud of.