Enjoy Every Sandwich

Thoughts on SQL, XML, .NET and sometimes beer.

<October 2008>
SuMoTuWeThFrSa
2829301234
567891011
12131415161718
19202122232425
2627282930311
2345678


Navigation

Tools

List O'Links

Kent's Other Stuff

Subscriptions

News

Please read these
Notices and Disclamiers

Post Categories

Article Categories



Joe Cooney asks the right question about Client-Side XQuery

Will there ever be a .NET XQuery implementation from Microsoft?

I think is yes only if:

  • Enough people "storm the gates" of folks like Michael Champion and Michael Rys demanding it.
  • Sufficient demand can also be raised for XSLT, since, apparently, the building of an XSLT2 processor could bootstrap an XQuery processor quite nicely.
  • Microsoft internal CLR team architectural mindshare leaders are willing to help resource the effort. The WebData alone probably lacks sufficient resources to do all they already have on their plates and this.

This doesn't even consider XLINQ. Part of the question that we the community need to answer is what doesn't XLINQ do for us as well as XQuery. Frankly -- having spend a good amount with both -- XLINQ wins if for no other reason that it gives us the ability to manipulate instances, not just query them. As I've said before, at least part of the reason that Microsoft doesn't have client-side XQuery in Whidbey (.NET 2.0) is that the standards body moved so slowly to produce a query-only spec. Yet clearly the need to both query and perform updates, modified and deletes on instances is really required by most applications.

So no, Joe, I don't think the stars are really aligned right for there to be client-side XQuery in .NET in the next few years. There's simply not enough user demand for it or for XSLT2 and, compared to XLINQ, its likely a lower priority for the team.

My biggest beef about all of this isn't that we likely won't have client-side XQuery or that we will have XLINQ. Pragmatically speaking, I don't care *how* I query as much as I care that I *can* query. However, as somebody that believes in open, community driven standards, I'm really disappointed to see things turn out like this. Some folks might say that "here's another case of Microsoft shoddly adopting a standard then trying to obsolete it." I really don't think that was anybody at Microsoft's intention here. Rather, management made the decision -- after looking at a number of alternatives -- and decided that it was best for their customers to go down a different path. Fine, at worst its shame on them for making that decision for us, but let's be honest: shame on us for not giving them a reason not to.

posted on Thursday, September 29, 2005 1:43 AM by ktegels





Powered by Dot Net Junkies, by Telligent Systems