Harvesting some LINQ links

This post summarizes some things we've noted in tracking the reaction to XLinq in the press and blogosphere, and points to some resources we've discovered along the way.

One thing we've noted in the LINQ forum and elsewhere is that people seem to think that LINQ == DLinq, i.e. that LINQ is just some C# syntax for embedded SQL.   As we see it, however, LINQ provides a model of data access that unifies query and transformation across an extensible set of domains, including .NET collections , XML data, relational data, ADO.NET datasets, and more in the future.  Other development environments (e.g. Java) support different languages and APIs for different types of data:  JDBC for relational data, XQJ for XML databases, Groovy for XML text, and so on. With LINQ, developers use a common set of language features to query and manipulate  XML, relational data (in a DBMS or in a cache), and objects. 

It's not so much a different syntax for embedded SQL as bringing a common set of query operators to all types of data that can support the IEnumerable<T> abstraction.  It may be asking a bit much to expect the relational purists to give LINQ a fair hearing, but in reality it is doing much of what they have long advocated - making it more feasible to work with data via something very much like and very much inspired by the relational algebra.  See for example Ted Neward's piece on LINQ and similar approaches. 

One particularly powerful area of synergy between the LINQ approach and the relational algebra is exemplified by the new LINQ join operators. Anders' talk with Jon Udell focuses on this new feature in the May CTP, and many of the examples show how to use various types of join operations to simplify common XML processing tasks.  People who have seen the podcast seem to agree: "Wow!".  This isn't PowerPoint ware, this is an hour of hands-on coding and explanation by LINQ/XLinq's principal designer.

Paul Kinlan asks if XLinq has an efficient way to process very large documents without loading them into memory first.  The short answer is "no, but we're thinking about this." It would be very good to hear from others about what their needs are, what kinds of XML data they are processing, why they don't use an XML-enabled DBMS such as SQL Server 2005 to do the heavy lifting, etc.

Finally, we came across an interesting blog by Kevin Hoffman that has a number of posts on LINQ topics.  My favorite so far is his explanation of lambda expressions and expression trees, a topic I have been trying to get up the courage to tackle my series on XLinq design issues in my own blog.

Be sure to let us know about any XLinq-related sites that you find interesting or useful, and feel free to contact us either via the Contacts link or the comments section if you have questions or problems applying XLinq to real XML problems.

Mike Champion