RJ posted an interesting entry about LINQ to XSD. The early LINQ to XSD bits that surfaced back in Orcas Beta 1 or thereabouts were basically an object layer of the underlying xml data. It was better than *just* an object model in that much of the XElement capabilities remained, but it was still just an object wrapper. I think VB can possibly do better ….
If you look at VB9 you’ll see there’s already basic intellisense support for schemas when working with XML axis properties. So the questions we should and could ask are can we make that better ? For example, let’s say the compiler was to validate that. We could then enforce XSD constraints and give warnings or errors when they are broken.
One problem would be how would you specify what schema is being used. What if the XElement or XDocument has multiple schemas or you want to apply a different schema to a document ? One solution might be to have Schemas as a form of Interface, or more to the point as a Dynamic Interface.
Now if the constrain is only via dynamic Interfaces, you get all the flexibility of XML elsewhere, but if you cast the element to that dynamic interface you are constrained to that schema.
So if we had that, then why not let Dynamic Interfaces be schema fragments ? Then you could strongly type an element as a branch of a schema.
I don’t think an object model is the best way of spanning that XML to general purpose programming divide. VB on the other hand has embraced XML and made the initial steps. Dynamic Interfaces seem like a logical extension to what VB9 already provides. And, speaking of extensions, if the schema or schema fragments are dynamic interfaces, then you could also provide extension methods typed to the dynamic interface.
There’d still be bits that would be more difficult such as interception of value setting, and eventing.. perhaps that would be the perfect opportunity for mixins