I finally got some time (18 hours in a plane to Seattle :) to settle down my mind about XLinq. Erik Meijer's excellent article, which explains XLinq from functional programming point of view made me changing my mind on some issues I wrote earlier, some hands on experience and some comments from smart readers helped me to see a bigger picture.
Dimitre Novatchev (father of XSLT functional programming) writes:
The fact that XLINQ is as it is reflects that it targets a completely different audience, who would never attempt to learn XPath :o)There is some truth in his words. But I don't want to be "completely different audience" actually, I like XLinq and I do believe it can make XML programming easier for masses. While tragetting innocent developers who are too
You are a person, who doesn't really need XLINQ and the authors of XLINQ had totally different audience in mind.
Most of your remarks in the remaining "Bitter words" also reflect this fact.
Taking the fact of the completely different audience targeted by XLINQ, many of the "shortcomings" for an experienced XML professional will actually be regarded as useful features for innocent OOP-ers.
The point is, LINQ is a general purpose language for querying and transforming data, so of course there will be cases where a domain-specific query language (like xslt) will be more powerful, more compact, or more expressive. Our hope though, is that for those common cases where you don't need the extra power, this will be (as one PDC-goer put it) 'the last weird query language you'll ever have to learn.'Well, the recipe is known:
Simple things should be simple. Complex things should be possible.
We haven't abandoned the people who know and love XPath, XSLT, and even DOM -- assuming there are some closet DOM-lovers out there somewhere ... I've never encountered one :-) These tools will still be available, supported, improved. The difference is that the newbie-friendly language support / APIs will not be grafted on top of DOM, but will be built from the ground up on .NET, C#, VB, etc.
Some points of convergence are still possible. For example *I* (definitely not speaking for Anders!) could imagine an XLinq method that took an XPath string and returned an IEnumerable over the objects that matched it. The trouble may be that that the lack of conceptual integrity in the XML standards stack makes this a lot more complicated than it sounds given the data model mismatches, the XPath namespace mapping challenges, and the XPath version 1.0 -> 2.0 changes. But still it might be something to look into IF there is real demand.
Alan Kay's recipe seems to have been the motto of the LINQ/XLinq team. The way I see it, Microsoft has spent close to 10 years now trying to make XML palatable for "lazy / afraid" -- I would say "overworked" -- developers, and has gotten a lot of pushback. Not many people with regular work to do want to learn the XML toolkits. LINQ is an accomodation of that reality to expand the reach of XML, not a betrayal of the ambitious / courageous / weekend-working :-) folks who have been the early adopters of XML.