Scott Hanselman

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.

or

"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]*"/>
    </xsd:restriction>
</xsd:simpleType>

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

private string amountField
  
[System.Xml.Serialization.XmlElementAttribute(Form=System.Xml.Schema.XmlSchemaForm.Unqualified)]

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 {     
    [DebuggerBrowsable(DebuggerBrowsableState.Never)]     
    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", global::ofx.net.types.Item2003.Item04.AmountType.TypeDefinition);     }
}

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

• Get namespaces from an XML Document with XPathDocument and LINQ to XML
• Hanselminutes Podcast 79 - LINQ to XML
• Improving LINQ Code Smell with Explicit and Implicit Conversion Operators
• New XML Schema Designer CTP released for Visual Studio 2008
• Mixing XmlSerializers with XElements and LINQ to XML
• WPF Sample in IronRuby talking via C# to Wesabe
• Putting Mix, Silverlight, the CoreCLR and the DLR into context
• Clever: XML to Schema Inference Wizard for Visual Studio 2008

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.

About   Newsletter

Hosting By