A long time ago in a galaxy far, far away… That’s not really the case, but it’s not far from it. In early 2007 I first read about the LINQ to XSD project which Microsoft (or rather, it’s xml team) was working on. I haven’t heard much news about this project since then, so I decided to write an e-mail to the xml team. It didn’t take long for them to answer my query (they seem to be similar to DLINQ in this manner) in a very short and concise manner. I’m not really sure about how I should interpret the response, however.
My question was (very compressed so you don’t have to read my entire e-mail): “I haven’t seen any news about LINQ to XSD in a long while. Is it a dead project? If it’s dead, could you give it to the community to continue?”
The answer I received from Pawel Kadluczka was:
We're currently looking at ways in which we might further the LINQ to XSD technology for its user community. We don't have anything to announce quite yet.
Well, the happy note here is that the project isn’t dead. The sad part is that I didn’t succeed in prying more information by nagging. :) I guess patience is the key, then. My thanks to Pawel for the e-mail!
What is LINQ to XSD?
I do so love type safety on my data classes. When I load data, be it from a database, a form post or an xml file, I do not want to touch things with Magic Strings. The best part? If I would correct a spelling mistake or change the name of an element, I would get a compile time error instead of run time. Therefore I am very much into OR Mappers and XSD class generators.
However, I have never been very fond of the xsd.exe application which generates .NET (C# or VB.NET) classes from an XSD file. There are several reasons for this, but my main complains is that it is a one way conversion (there is not enough information in the generated classes to be able to recreate the XSD file from them) and that I can’t use the generated classes to validate that the data in the structures actually satisfies the constraints of the XSD file. An example of this would be a string constrained to the length of 20 characters in the XSD. The code generated by xsd.exe does not contain the constraint information and I can thus not (easily) verify whether or not the data in my objects are valid according to the constraints in the XSD file.
On a white horse, riding in the sunset with a glass of milk in it’s hands, “LINQ to XSD” comes to the rescue. LINQ to XSD, like xsd.exe is a tool which generates classes from an XSD file. LINQ to XSD is (or will be) more integrated into Visual Studio than xsd.exe is. Just set the build action of the XSD file to use LINQ to XSD and it will re-generate the classes for you when you compile your project. This also means that once you have set the build action and compiled your project you will get the wonderful thing called Intellisense. Also, LINQ to XSD (not surprisingly, due to the name) also makes the resulting classes very easy to use efficiently with LINQ to Objects (and further also PLINQ).
An example of using LINQ to XSD and then LINQ to Objects over the generated objects would give something code like the following (Since I cannot install the LINQ to XSD alpha at the moment, I’ll just steal the example the xml team is using in the LINQ to XSD overview document)
(from item in purchaseOrder.Item select item.Price * item.Quantity).Sum();
which would sum the price of all items in the following XML file.
<purchaseOrder> <item> <price>12</price> <quantity>2</quantity> </item> <item> <price>24</price> <quantity>1</quantity> </item> <item> <price>17</price> <quantity>2</quantity> </item> </purchaseOrder>
and given that the XSD file would specify the price element and the quantity element as integers, the result of the call would be 82. And all this without any explicit casting in the code that uses the loaded data.