Michael Rys says in a comment on the previous post "I personally think that XQuery is not bad for having been designed in a committee overall (compared to the DOM :-))" These continuual slurs on the DOM! Everywhere I go, even from my closest colleagues, sniff. :-) 

Neither DOM nor XQuery are "bad" for having been designed by committee; my point is that no rational person would argue that they are as elegant as LINQ.  That doesn't necessarily mean that LINQ will be more successful in the marketplace.  My favorite comeback to the "DOM is the proverbial camel designed by a committee trying to create a horse" is that camels are more sturdy beasts than horses, especially if you are exploring in the desert.  DOM is actually a remarkable sucessful spec, even though it is not well liked by most of the users I talk with.  Actually most of the things Anders, and Elliotte Rusty Harold (who developed the Java-specific XOM API) don't like about DOM were features not bugs - it is language neutral, interface oriented rather than class oriented (it was intended for companies to use on top of their existing HTML and XML internal data structures and object models, not to replace them), it *is* essentially an InfoSet assembly / disassembly language (we thought there would be competition among designers/implementers of "convenience classes" that would live on top of the low-level DOM). The kludgy namespace support, and general weirdness for things like entity references, has to do with the kludginess and ugliness of the underlying specs, IMHO, not to mention the fact that DOM Level 1 came out before the Namespace spec was final.   The namsspace spec was a fast-moving target in 1998 ... and if DOM had missed the IE5 (and, we thought at the time, the Netscape 5) spec freeze date, it would have been Game Over.  I think that XLinq has a much cleaner namespaces model, but that comes from ignoring the principal design point for namespace prefixes - to make XML documents easier to type. 

As for XQuery, well we will just have to see if it succeeds BECAUSE it is such a potent gumbo of good ideas, or if it fails because some of the chunks are too big and some of the shrimp weren't cleaned very well :-)  I think that XQuery and XSLT will both find secure niches because when the evening rush comes, you've gotta serve the customers and they care more about how fast it is served up than how clean the kitchen (or sausage factory) is. Less metaphorically, when performance (and portability, standards-compliance, etc.)  is critical the fine-grained control of these standardized specs will give real advantages, especially deep down in the infrastructure away from the people who don't have to process large quantities of XML themselves. I personally lost most of my interest in XQuery as a client side development language -- targeted at people who need the power of XSLT but without forcing them to turn their brains inside out -- once I learned about what we now call LINQ.  My guess is that the mainstream developers that Microsoft caters to will feel likewise.

No discussion of this subject is complete without these important links .