The XmlFormatter Architecture in Indigo

 Indigo will ship another object <--> XML “converter“, the XmlFormatter. The XmlFormatter feels like the successor to the SoapFormatter. It doesn't have the limitations of the XmlSerializer, but doesn't allow for the customization of the output format. Here are the features in more detail.

• XmlFormatter will extend the existing Formatter family. Existing SerializationBinders will continue to work and while the XmlFormatter can produce the text-based Xml representation that the world it used to, it isn’t limited to producing a character based output. The XmlFormatter should be called the InfoSet formatter. It operates at the InfoSet level and doesn’t necessarily format to a text based format. I can also serialize to binary Xml or other format that represent the InfoSet.
• Serialization in Indigo is fully attribute-driven. Members that should be serialized have to be marked with the [DataMember] attribute, which will cause member to be serialized regardless if they are private or public, field or property.
• The XmlFormatter can produce Xml output for thightly and loosely coupled systems. In the thightly coupled scenario the XmlFormatter will embed CLR type information in the serialization stream, just as the SoapFormatter did in the previous versions. The serialized format can only be serialized back to a type that is compatible with the type of originally serialized object. In loosely coupled scenario, it’s undesirable, or unreasonable, to assume that compatible types are available to cooperating services. The contract that cooperating services enter should be based only of the shape (i.e. the schema) of the data that they exchange. It should not make any assumptions that contains type information that is specific to an environment. The XmlFormatter can omit any type information in these scenarios and operate very similar to the way the XmlSerializer is working today.
• The Indigo XmlFormatter architecture introduces a set of events that allows objects to influence their serialization and deserialization process. The events scheduled for Indigo are OnDeserializing, OnDeserialized, OnSerializing, OnSerialized.
• The XmlFormatter can receive type information to modify the default projection of a type via a SerializationContext object. The context contains custom mappings for types, again similar to the way you could previously do with XmlInclude attributes or passing Type arrays to the XmlSerializer today.
• The XmlFormatter succeeds the SoapFormatter and is intended for interoperability and service orientation. However, it is not intended for situations where you need to care strongly about mapping to an XSD type. It employs a canonical algorithm to map the serialized to a schema when you need embed an XmlSchema for your types in a WSDL for example. This algorithm also includes extension points to allow for future extension of the serialized classes in a schema-valid, interoperable way.
• The XmlFormatter can support Hashtables … finally … again, in a schema-valid way, by using specially defined schemas can define a serialization format for a hashtable.
• When importing types from XML schemas embedded in a WSDL, Indigo employs a tiered approach to virtually support every schema type. The WSDLGEN tool will first attempt to generate classes that can be employed to deserialize into CLR types. If the schema contains types that are not compatible with the XmlFormatter, the Indigo infrastructure will not attempt to deserialize the message and hands back an XmlReader or the raw message.
• And finally, Doug told us: COM isn’t LOVE. Indigo is Love!!!