Scott Hanselman

LINQ to Everything - LINQ to XSD adds more LINQiness

February 23, 2008 Comment on this post [11] Posted in LINQ | Programming | XML
Sponsored By

It's funny when you work at a company that has as many small projects as it has big ones. I hear one of two things:

"Is _______ dead? I haven't heard anything in a month from _____ team's blog! It must be dead.


"Can you just stop with the 99 different ways to do _______? There's more happening that I can handle."

I'll try to help with the latter in the coming months. Even though we hear about technologies like LINQ to SQL and LINQ to Entities or ASP.NET MVC and WCF and get confused about if they are complementary, there is (usually) a plan behind the whole stack, even if that plan isn't very well-communicated. I'll do a diagram or two to help soon.

But first, looking at the Is ____ dead? question. It'd be cool if someone just dropped a blog post as a "ping" every few weeks like "We're still here! Nope, not dead!" kind of like an Out of Office Response, but for blogs.

For example, LINQ to XSD was mentioned in June of 2007, looked rockin' sweet, and then went silent. However, small teams like this continue to move the ball forward, but we (the outside world) don't hear from them. I'll try to find those projects and ping for the people.

Just yesterday, LINQ to XSD surfaced (I actually had a video call with them on Weds) with a new release.

LINQ to XSD creates .NET classes with much better fidelity than what's created with (the aging) XSD.exe. Now, of course, XSD.exe makes classes for XmlSerialization, while LINQ to XSD makes classes that use an XDocument (not XmlDocument) as the backing store, so we are comparing Apples to Carburetors, but if your goal is to get Objects that come from an XML source, you should take a look at LINQ to XSD.

For example, if I take one of the goofiest schemas, OFX, a financial services schema (disclosure, I was the Vendor Committee Chair for OFX for a few years so I'm to blame a bit) and run it through LinqToXml.exe, here's some differences.

For example, in the XSD for OFX there's some types like "Amount" that have Restriction Facets. The type is a string, but it must match a certain regular expression, like:

<xsd:simpleType name="AmountType">
    <xsd:restriction base="xsd:string">
        <xsd:maxLength value="32"/>
        <xsd:minLength value="1"/>
        <xsd:whiteSpace value="collapse"/>
        <xsd:pattern value="[\+\-]?[0-9]*(([0-9][,\.]?)|([,\.][0-9]))[0-9]*"/>

However, when that's turned into generated code via XSD.exe and XmlSerialization, we get:

private string amountField
public string AMOUNT {   
get {        
return this.amountField;    
set {        
this.amountField = value;    
} }

Which kind of sucks, from a fidelity point of view. We've lost information, the restriction is gone and the Type is gone.

Here's the same thing generated with LINQ to XSD:

public sealed class AmountType {     
public static Microsoft.Xml.Schema.Linq.SimpleTypeValidator TypeDefinition =
new Microsoft.Xml.Schema.Linq.AtomicSimpleTypeValidator(XmlSchemaType.GetBuiltInSimpleType(XmlTypeCode.String),
new Microsoft.Xml.Schema.Linq.RestrictionFacets(((Microsoft.Xml.Schema.Linq.RestrictionFlags)(46)), null, 0, 0, null, null, 32, null, null, 1,
new string[] { "^(([\\+\\-]?[0-9]*(([0-9][,\\.]?)|([,\\.][0-9]))[0-9]*))$"}, 0, XmlSchemaWhiteSpace.Collapse));    
private AmountType() {} }

...and...then the accessor:

public string AMOUNT {     
get { XElement x = this.GetElement(XName.Get("AMOUNT", ""));        
return XTypedServices.ParseValue<string>(x, XmlSchemaType.GetBuiltInSimpleType(XmlTypeCode.String).Datatype);     }
    set { this.SetElementWithValidation(XName.Get("AMOUNT", ""), value, "AMOUNT",;     } }

Note that this is generated, so don't judge it on aesthetics, it's about the experience as a consumer of the API. This is cool because we don't lose anything, the mapping between CLR type and XSD type is clean enough, you get a real type, but you can still access it as a string. If you set a value it's validated on the fly.

Remember again, this is an interesting, if biased, comparison as LINQ to XSD uses an XDocument as the backing store and its properties access the DOM, while XSD.exe/XmlSerializer makes copies using dynamically generated temporary helpers and XmlReaders/XmlWriters to make Objects out of your Angle Brackets.

Another good example of a quiet team that still has cool stuff coming is LINQ to SQL as they update for SQL 2008.

Dear Reader, what's the best way for a team to tell you they are not dead?

Related Posts

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Hosting By
Hosted in an Azure App Service
February 23, 2008 6:40
Post to the team's blog more often than just when there is a release. Every day someone on the team is going to have to make a decision. Or they're going to struggle to make a hard decision. Those are blogworthy and show what kinds of thinking are going into the product. "Today we decided we're going to implement rotarian infrigitors using alpha protases." is interesting to whomever is following a particular product's blog. Or, "Today we discussed how best to work around [insert technical difficulty here] and are considering a couple of options [briefly describe]. Which one should we choose and why?"

Mr. Haack has just been doing a good job of showing this kind of thinking with his discussion of interfaces vs. abstract base classes. That's what teams can do to show they're still actively doing stuff.
February 23, 2008 7:16
Hmmm... I was thrilled with Foldershare for a brief while, but it's been an up-and-down service ever since 2005 when Microsoft acquired the company that created it. Although it was moved into the Windows Live family of products/services, the website has hardly changed (on the Download page that Vista isn't listed among the Windows versions!), and I can't seem to find a blog for the team, but I agree with Steve Smith that it would be great for the team to keep up with the public in a format such as a blog. There is a discussion group, and sometimes Foldershare team members try to help and post to it. But rarely is any information provided about new releases, and no roadmap has been announced. I've since moved on to another method for file synchronization (Second Copy, which won me over because it could be run as a service), though it's not as automatic as Foldershare.

- David McClelland
February 23, 2008 19:54
Another way to indicate a project isn't dead is to respond to questions about its status in the appropriate MSDN forum.

I requested the status of LINQ to XSD for .NET 3.5 RTM in a LINQ Project General forum Status of LINQ to XSD for RTM? on November 17, 2007. Two others seconded my request.

Not a word from the XML team.

I'm trying again with a status request for Shyam Pather's LINQ to Stored XML implementation, but I'm not optimistic about the result.

February 23, 2008 20:47
Off-topic, Did you try "" ?
February 24, 2008 3:06
how readable is that example? You need to be a theoritical mathematician to understand this. You do need to check for readability and elegance. I prefer the first methode anytime.

February 24, 2008 17:07
Hi Scott,

This looks interesting. However, I don't have access to VS2008 RTM today. Is there a way to get the LINQ to XSD code generator as a standalone EXE?
February 24, 2008 18:42
what's the best way for a team to tell you they are not dead?

By posting nightly builds, of course ;)
February 25, 2008 10:02
what's the best way for a team to tell you they are not dead?

By posting (bi-)weekly updates and keeping the (RSS) reader burning. If you have a beta project or a work in progress, get readers to subscribe (e-mail or RSS) and then ping once every week or two, preferably via a blog post.

Honestly, you can even get away with a "no news to report"-style of post likely once / month, interested parties just need to hear that "we are working, here's what we're up to". It sounds inane, but effectively, we (the developers) are your customers. You can't just give "status reports" to managers, you have to give them to customers too.

Jensen Harris, made a big buzz with his Office UI blog. Just check out the number of comments. And seriously, to most of the nerdy, leading-edge developers who surf the blogs, the new Office UI is one of the least interesting things around. For every 1 blog-surfing developer who wants to hear about the new office UI, there's a different one who wants to hear about LINQ to XSD.

Maybe it's worth taking a new approach when it comes to developers and new technologies. Here's what developers are thinking:
- If it doesn't have a blog, it doesn't exist, it's not being worked on.
- If it has a blog and that blog hasn't been updated in 1 month, then the project has been nixed and no one is working on it. (next version of Office, no cool UI features, I "know" this b/c I haven't heard a peep from Jensen in months)
- If the technology has no targeted release date (or some ridiculous release date that no one will believe anyways), then we'll happily listen in as that date approaches.
- If releases are more than 2 months apart for any project that isn't VS, the .NET Framework, SQL Server, BizTalk, Sharepoint or an OS, then we're just going to figure that resources have been redeployed elsewhere.

The XML team has had 7 posts (!) since that June 5th post and one of them was "Happy 10th Birthday XML". As far as I'm concerned the "XML team" is probably just a group of guerrilla MS developers who have 5 other projects and do this in their "spare time". They have 3 releases since that time (one beta, one CTP, one VS add-in). Unless there are like 2 people on that team, we just expect more than 6 blog posts and 3 releases (on separate products).
February 28, 2008 18:54
"I prefer the first methode anytime"

The first method is obviously going to be more readable, mainly down to the fact that it is functionally incomplete and doesn't map to the XSD. Show me validation code that doesn't complicate understanding of the intent of the code even without factoring in the fact that the code has been generated by a tool (I've worked with a few 'tools' in my time, and some of them produced even more hideous code!). Then if you factor in the fact that the tool that generated it is version 0.2 Alpha, I think it's pretty good because it is readable, and I doubt that you would ever be debugging into this code in isolation from the actual original XSD anyway.

As a user of XSD.exe, it always struck me as bad that I was creating an XSD which is explicit about valid data for a particular field and then I was having to reimplement this in code as well, introducing versioning problems across the board.

I've had a quick play around with LINQ to XSD against our previous XSD.exe'd stuff and it looks to have potential.

Looking forward to future versions.

Thanks for the heads up Scott
March 09, 2008 14:39
Hi Scott!

What would be the best way to integrate the classes made from the "LINQ to XSD" tool with the classes you get from the "LINQ to SQL" tool?

I now have the ability to make classes based on a database-schema, and a tool to make classes from a XSD. How do I "close the loop"

Keep up the good work!

Jo Erik
March 25, 2008 19:12
@Jo Erik Hesthagen

That's where the problems with those start. Netiher one works with something called "domain model". They both generate classes, not mapping. You could bridge the two, but that's the upside-down approach, the value of such bridge seems questionable to me. LINQ to Entities or NHibernate is half of the answer in such case. What I'd like to see is similiar mapping for XML, or object-to-object mapping to map domain model to the generated classes.


Comments are closed.

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.