General XSD Limitations

The XSD tool is mapping type definitions between the .NET type system and the XSD type system. The two systems address different computing needs, so naturally they don’t map onto each other seamlessly. The next sections will outline the differences between the two type systems and show how the XSD tool maps common XSD constructs to the .NET world.

The XSD type system is very data-centric. We find many concepts we also find in databases in the XSD type system, for example key references and uniqueness constraints. Yet, we the XSD type system also supports concepts from object-oriented programming, like complex types and inheritance. The .NET type system, on the other hand, is truly object-oriented without much regard for data-centric features. The .NET Framework provides the XML serialization attributes to provide hints directly to the XmlSerializer when we design classes for serialization to bridge some of the gaps between the two type systems. Some features of the XSD system, however, are not supported with the XmlSerializer today. Specifically, these features are:

• Predefined array sizes with the minOccurs / maxOccurs attributes.
• Restriction inheritance through restriction. The <enumeration> <restriction> can be expressed in the .NET type system through an enumerated value.
• Uniqueness constraints as expressed by <unique>.
• Referential integrity constraints expressed by <key> and <keyref>
• The mixed content model. Minimal support for mixed content can be provided by applying the XmlTextAttribute metadata attribute to a field.
• Separation of types and instances, multiple top-level elements can reference the same type. There is no equivalent concept in the .NET type system; two classes can not share an identity.

The XSD tool leaves it up to us to enforce the missing features. We can either modify the classes the XSD tool generates directly or develop special validator classes. In many cases we can replace the generated fields with a property and add the validation logic into the property accessors. In some cases this approach fails because validation involves multiple fields, of which some may not be deserialized yet. For example, you might deserialize an object reference before you deserialize the referenced object. In this case you cannot run any validation when you deserialize the reference. You may find that encapsulating all validation code into dedicated validation classes works better for you, because you don’t have to manipulate the generated classes.