The world has had a chance to look at the LINQ technologies a bit, and the overall response has been quite enthusiastic. But now we're getting some harder questions about how various LINQ components relate to one another and to existing Microsoft technologies. Let's compare XLinq --- oops sorry, LINQ to XML -- with some alternatives to tell the story of why we are building it and what that means for those who know and love the current generation.
One basic question keeps coming up, something like: "We have SAX, DOM, XmlReader/Writer APIs (and the Java people have a bunch more), we have XSLT, we have XQuery ... why do you think we need Yet Another XML API?"
First, XML is just too hard -- or at least too tedious -- to use for mainstream developers today. Non-specialists using XML today tell stories that remind me of various home improvement projects gone awry. As a weekend home improver, I want to focus on making things look nice and do useful things, not on the slimy details of connecting tubes of different materials, diameters, and states of corrosion together in a way that doesn't leak. Likewise, people using XML to improve their software's interoperability generally want to focus on the areas they know and care about, and not on learning the subltle points of one API for efficient large document reading, another API for convenient small document tweaking, another technology for structural transformation, and yet another for database access.
That's not to say that we are designing LINQ to XML (I'm just going to abbreviate that "XLinq" below until there is a PR-approved shorthand) to replace XmlReader, DOM, XSLT, and XQuery. These will all live on, somewhere in the Microsoft stack, for the forseeable future:
Second, there have been quite a number of developments in programming languages since the SAX and DOM APIs were designed almost a decade ago. Back then, cross-platform APIs based on CORBA were "hot", interfaces/factories often preferred to concrete classes, and few widely-supported and understood collection mechanisms other than the array. Now RPCs are in disfavor, concrete classes generally preferred, and generics introduced to make it much easier to process collections of objects in fairly standardized ways. Furthermore, additional features such as nullable types and functional constructors are in widespread use and APIs are expected to support them. We believe that an XML API designed with with these "modern" tools and conventions in mind will be more familiar and usable to today's programmers than APIs designed with 1990's conventions in mind.
Finally, we believe that the overall LINQ story is going to have a pretty profound impact on data programmability, and we want to make sure that LINQ has a good story for XML. Serious thought was given to the challenge of LINQ-enabling the existing APIs, but no satisfactory designs emerged. LINQ adds features to C# and VB that were quite openly borrowed from more "declarative" languages such as SQL and "functional" languages such as Haskell. This may give purists some heartburn, but we believe it will give mainstream developers lots of new power in a familiar package. For XML users, I see a few really powerful implications:
We get a bit of rude Q&A on these points:
Why not just fix the existing APIs? One hard lesson I've learned as PM for the DOM APIs is that it is almost impossible to accept the suggestions we get to improve the conformance, performance, usability, etc. of the existing APIs without breaking existing applications. Just adding new features without breaking the behavior of old ones creates even more confusion and complexity
Why will XLinq succeed in the .NET world when JDOM, dom4j, XOM -- which offer cleaned-up, modernized, native platform-friendly XML APIs -- have not displaced the DOM in the Java world I raised this on the xml-dev mailing list and got some very interesting responses. The essence of matter seems to be that a) the sophisticated Java developers who know about them do use one or more of these in preference to DOM; b) Java platform vendors, however, have not embraced or evangelized any of them; c) mainstream users often don't know they exist, or d) their managers discourage use of them because they are not considered "safe" alternatives. We don't think Xlinq will have these problems, simply because it will come from Microsoft and have the full weight of the company, its education / evangelism, and its support policy / staff behind it. We are confident that developers who are exposed to Xlinq will frequently choose it for their XML programming needs, and their managers can feel confident that this is a safe, supported choice.
Are you just smoking your own [insert mind-altering substance here] or do you have evidence that real people will find XLinq powerful yet easy to learn and use I can't go into much detail, but we have quite a bit of evidence. Indeed, we have a bit of a problem because so many Microsoft developers who are exposed to Xlinq want to use it before it is really ready to take a dependency on. One project taking heroic measures to work with the XLinq API; another discovered that its Xlinq-based prototype was about 1/3 the amount of code as the DOM prototype; and most agree that it makes XML almost a pleasure to work with.
Let us know what confuses or angers you about this story. I'll do my best to clarify what I can, and try to fix the rest.