XQuery vs. XLINQ? Sorry, but that fight was over before it began.
By now, I think everybody that reads the blog on a regular basis probably knows three things about me:
- I really like XQuery
- I really like .NET
- I really care about Databases
But that doesn’t mean that I’m all that thrilled with XLINQ even though it’s the intersection of those three things. That’s not to say that I don’t like or see the value of LINQ in general -- in my opinion it is a no-brainer and I’m very excited about it. But I do have a few non-technical nits to pick.
First, I can’t help but see the emphasis in delivering XLINQ instead of XQuery on the client side as anything but Microsoft creating and encouraging barriers between .NET and other technologies. With a working knowledge of XQuery, there was at least the idea that I could learn that and either Java or a .NET managed language and be able to more easily transition between the two worlds. XLINQ effectively means that I have to learn two different ways of doing things since what I know from the Java side isn’t doable with .NET. Sure, yes, there are many mutual instances where that’s true, but this is one that didn’t have to exist.
Second, the real value for me in XQuery wasn’t that it is "easier than XSLT" but rather, it is could have been a standards-based portable, universal way to query data. SQL tries to do that, but it is so Balkanized that truly portable code is either trivially useless or so rare and less than optimally efficient that it is just not worth the average developer’s time to invest in. Combine XQuery with semantically-enhanced schema (e.g., OWL) and we really could have build platform-agnostic, highly distributed queries over data, documents and knowledge. Maybe not terribly efficient ones as we understand things today, sure, but it is/was certainly doable.
Personally I liked the idea of XQuery as a fully-fledged scripting language for one simple reason: it would have been a good mixing of imperative and functional languages for solving a certain class of problems. And being standards-based, it certainly could be one heck of an uber-language. But I loathe the idea of XQuery as such because it made the language a lot more complex than I needed it to be a pure query language in order to accommodate such things. Then there’s the limitation was that it demanded an XML API over the data too. Yes, of course its possible to have such a thing for just about everything, but it also always going to be less than optimal performance wise for non-XML native stores. I do think that problem was/is largely addressable, but I fear we will probably not know that on all platforms in this decade now.
Finally, I don’t really believe that Microsoft should change course, at least right now. LINQ is powerful stuff because it really does enable anybody to learn mostly patterns rather than both patterns and language. And thanks to its internals, it enables a lot more on the Microsoft platform than query over XML alone does. The real power of LINQ isn’t that it frees us from learning anything but that it focuses the learning and knowledge at a higher level than we’ve had before. That’s certainly a good thing.
It is because of this last point that I’m not interested in trying to prove that XQuery is better than XLINQ. Way smarter people at Microsoft -- with lots more knowledge and internals awareness of building XQuery processors -- have already been involved in the development of XLINQ. Oh, am I sure there’s something they might have missed or overlooked about XQuery, but even if I did find something like that, I’d certainly vote first to have it incorporated into LINQ rather than to use it as reason to force Microsoft to give us client-side XQuery. Why? Again, it is the patterns, not the language, that matter the most. Chances are that the semantically same problem would manifest itself in trying to replace T-SQL with DLINQ at some point. If you look at LINQ like do -- as a common query runtime -- it only makes sense to make that as strong as possible and then build good language-specific query compilers over the top of it.
So for me at least, XLINQ wins by a technical knock-out before even getting into the ring. It really wasn’t going to be a fair fight though, was it? The underlying architecture of LINQ really fortify it the point where XQuery isn’t even in the same class. It’d be like a young Mohammed Ali boxing Superman.
And frankly, the rest of the world needs to pay attention here. If Sun really wants Java or the communities really want languages like Perl and Python to compete, they’d need to start banging the query integrated into language drum loudly and quickly too. And the XQuery community? We’d better get the message too: we’re mostly welcome in the Microsoft database world, but we’re going to have to learn something more to be effective and efficient at the Application level. Either that or we better be finding some Kryptonite-line boxing gloves quickly. Sad, but not bad. We gain more than we lose in the long-run I think.
By the way, if you think this is the end of ADO.NET... not so fast my friend. ADO.NET provides a lot of the essential plumbing under DLINQ and I wouldn’t be a bit surprised to see it be the way we work with WinFS in the future. The hard part of ADO wasn’t it the object model it was writing a data provider for it. If you want to see something that’s really improved, just compare writing an ADO.NET 2.0 Data Provider to writing and OLE-DB provider.