I love PVRs. They let me timeshift television shows so that I can watch whenever I want. One good thing about PVRs is that I KNOW what I'm watching isn't stale. I know that the ten episodes of "The Daily Show" on my Media Center aren't all current, but heck, they're still hilarious.
Timeshifting on MSDN TV is a different story. As Jeff noticed, MSDN decided to post an episode that mfussell taped earlier this year. As with just about everything that Microsoft develops, there has been a significant amount of thinking and churn that's happened since then....making portions of the episode completely incorrect. Lesson learned: Timeshifting on MSDN TV is not a good thing.
Oleg picked up on Jeff's post and expanded on some of the disappointments he sees with what we're shipping in Whidbey now compared to what the episode said. Although I agree with some of his gripes (some of this stuff should have made it into V1.1), I think the main problem is we haven't done a good job of explaining why we made some of these changes. I'm partially to blame for that, so let me try and rectify.
XmlDocument is (once again) the preferred store for XMLToday, V1.0/1/1, there's the XmlDocument which virtually everybody uses as their XML store. There's also the XPathDocument which has better performance in some query scenarios, but it's not editable.
At the beginning of Whidbey, we took a look at the XmlDocument and "decided" that the performance can't be fixed. So what's the answer? Bolt all sorts of interesting features onto XPathDocument! Editable XPathNavigator? Add it to XPathDocument! Type support? Add it to XPathDocument! Later in the cycle, we decided to reinvestigate the performance issues of the XmlDocument. Thanks to some work done by the CLR team in Whidbey and some fresh eyes, we realized that maybe the performance issues weren't insurmountable. So what's our new story for XML stores? Keep using the XmlDocument. You now have typing/validation support and editable XPathNavigator support (Jeff should be happy). We're also doing a lot of performance work so that we can effectively obsolete the XPathDocument in the long run. BTW, addressing performance and usability of the XmlDocument is going to be one of my main objectives going into the future.
XQuery/XSLTThis should be an entire post, possibly even a book, in itself. As the Program Manager for XSLT and XQuery in Whidbey, this is a subject near and dear to my heart. I'll try and cut to a few fundamental facts on this one...of course I'm sure there will be some lingering questions/disagreements from many of you:
- Neither XQuery 1.0, nor XSLT 2.0, will be finalized until probably the end of next year (2005). <opinion type="personal">Based off how many times both of these specs have already slipped, literally, years; I'm not confident even on that timeline.</opinion>
- Whidbey is scheduled to release before this time. Regardless of whether Whidbey slips beyond this, we can't plan our release on this fact. <opinion type="personal">I don't think Whidbey will slip. Recently, the organization has done an excellent job of locking down this release.</opinion>
- When we say that we're not going to support something, this goes for pretty much EVERY feature, it simply means we're not shipping in our stack at that point in time. We may implement it down the road. It does NOT mean we've written it off completely and forever.
- When we do decide support something, it should have a pretty long lifetime. XQuery 1.0 and XSLT 2.0 are huge undertakings. Writing an implementation is, surprisingly enough, is one of the simpler factors. Making sure it's scalable makes things a little harder. Getting the quality high enough so it's enterprise-ready (btw, this is much, much more than passing XYZ test suite) is pretty difficult. Getting tooling support like query generators, debuggers, and profilers is a substantial amount of work on top of everything else. Investing this much into a couple of unfinished standards? Maybe not the best idea.
So was XQuery a black hole? Maybe, but some good came out of it. For example, we came up with a new query architecture to support both XSLT and XQuery. Our Whidbey XSLT implementation is built on this architecture and the performance of this implementation, well, blows the socks off XslTransform. Another major benefit was our ability to provide feedback to the XQuery/XPath working groups in finding issues in the standard. This aspect of early implementation is often trivialized, but it's an important step in validating a standard.
The remaining 95%There are literally hundreds of enhancements that were made to the rest of System.Xml in Whidbey from simple things like implementing typed accessors on XmlReader/XmlWriter/XPathNavigator for usability to rewriting the XmlReader to double its performance...Not to mention the new XML tools support in Visual Studio (should be another book in itself). Sometimes our team doesn't do the best job of conveying this information because we become too enamored with some specific problem-set we're trying to solve.
As you can tell from my blogging history, I don't have the best record in terms of regular posts; maybe that will be my New Year's resolution. However, I'm always accessible via email. My alias is arpande. If you have any questions or want to start a friendly debate, feel free :)