Dude, where's my XML?
As I looked over the TechEd session list, I was thinking “Where is the XML?” A few years ago, there would have been DOM, hierarchical XML data, XSLT, and other sessions speaking directly about XML; every timeslot would have had something to satiate the buzz-word crazed masses. Not this year . . . or so I thought. What really has happened is that XML is maturing beyond the buzzwords and being baked into applications and frameworks so that it's behind the scenes, driving the solution even though the user may not know it. The SharePoint talk I attended involved sending messages using xml as the message format. The BizTalk product (which I learned is Microsoft's largest pure c# application at 1.8 million lines of code) routes and receives based extensively on XML; the BizTalk Maps and Schemas are all building on XML. Web Service Enhancements version 2 relies on SOAP (a specific XML standard) for messaging. Even though XML doesn't figure prominently in the session titles and abstracts, XML is certainly present at TechEd in a profound way.
That being said, there was one particularly xml-focussed session given by Mark Fussell entitled XML Today and Tomorrow and it was very interesting. He ran down a few main XML features in the .Net Framework today and compared them with what's coming tomorrow in Visual Studio 2005 (aka Whidbey). Mark asked the room: “who is using XPath today?” and the show of hands was only around 10%; apparently, my blog post on XPath back in 2003 hasn't taken the world by storm (or the other XPath proponents out there). Mark affirmed that XPathDocuments have a better DOM API than XMLDocument and are considerably quicker than XMLDocument -- use XPath unless you have a good reason not to. XMLDocument loads the whole xml file into memory and is generally more sophisticated than XMLDocument. This isn't new information. What's new is that XPath will get 20%-40% faster in the next version of the framework because they've rewritten the xslt processor from the ground up. Furthermore, we're getting an XPathEditableNavigator in the next version (v2 hereafter) that lets us modify the xml in memory. XMLDocument isn't going away, but XPath is where Microsoft has invested it's energy.
Are you sitting down for this next part?
XSLT will be compiled in v2; they'll generate MSIL from the XSLT! This also means a PDB file (a debugging file) can be generated from the code which means . . . you can step through the XSLT file as it processes a document with full VS.Net debugger support (Locals window, etc.). When you process a transformation, you can step into the xslt seamlessly; it's fully integrated into the VS.Net debugger. Mark demonstrated this and I saw it with my own eyes. Where was this during my hellish months with the “Microsoft B2C Reference Architecture based on XML and XSLT for Commerce Server” project so many years ago? I can't find anything official about that Reference Architecture because, I think, the reference has been set to null and marked for garbage collection! It wasn't a bad architecture, just very XSLT intensive at a time when there were no XSLT resources around. Debugging XSLT would have saved the day (and possibly the project).
Generally, XML v2 will be faster. XSLT gets 400% faster because it's compiled; XMLTextWriter and XMLTextReader get 100% faster. Performance has been a knock on XML solutions in the past, so this perf gain is great news. “I love perf!“ exclaimed Mark Fussell at one point in his talk.
Until version 2 becomes available in Visual Studio 2005, get on the XPath train and start working with your XML faster and easier today; when tomorrow roles around, you'll have an easier time taking advantage of the new stuff.
Happy .Netting!