Xml Serialization is loose coupling when it comes to type fidelity. If you can accept this definition of loose coupling as "things which behave independently of each other or at least explicitly state what the relationship is", then the Xml flavor of object serialization is loose as opposed to Binary or Soap serialization which is tight. I mention this because without going into details I had this misconception that the code for performing serialization on the server had to be the same; e.g. the same assembly, as the code doing the de-serialization on the client. This is not true and in fact there is so much control in the case of XmlSerialization at least that given a piece of Xml it should be very easy to engineer a type that matches it and allows you to come up with an Adapter class that deserializes the Xml into a .Net CLR type. This is extremely useful since with serialization you aren't writing code to manipulate an Xml Dom. That is so old hat; the .Net FCL gives us much better tools with the 3.0 serialization upgrades.

In the spirit of Xml there is no enforcement of the object's data type with respect to matching assemblies on the part of the serializing agent and the de-serializing agent. For instance with Binary Serialization the Binary Formatter persists not only the field data of the object(s) but also each types fully qualified name and the fully qualified name of the defining assembly (name, version, public key token, and culture). The SoapFormatter persists traces of the assembly of origin through the use of an Xml namespace.

However the XmlSerializer does not attempt to preserve the full type fidelity and therefore does not record the type's fully qualified name or assembly of origin. The reason has to do with the open-ended nature of Xml data representation. After all Xml is intended to be cross platform data so insisting on type fidelity during serialization through something like an assembly match doesn't make sense; after all you might be sending data to a Mac or a Linux box ( if their lucky they are using .Net with MONO but that is another topic ).

This is a good thing if you are using serialization for CLR type security and Xml for data interchange and you are worried about having the data be tightly coupled to a particular flavor of the code; e.g. you would have to release a revision to the code in order to change anything about the data; or even worse you updated the code and the old data was suddenly incompatible. Relax J XmlSerialization is F-L-E-X-I-B-L-E.

What I mean by that is if you are writing an application you want a lot of cohesion in your data.  You should basically be striving for POX (plain old XML ) data types. Resist the temptation to load up your data classes with code and properties that aren't part of the data but are intended to support the application.  That is what Model Classes are for!!! So you transferring data as XML Elements should be adquate in the vast majority of cases.  Failling that I can't imagine a scenario where you could not write an Adapter class that conforms to the Xml; say you get some existing XML and you want to make your application compatible with it AND you want to convert this into 'normalized' data.  You have an existing data class that is serialized; so now you use the Adapter pattern and then use Aggregation with the compatible existing type and the rest of the application treats the data normally.  So rippling changes up through a lot of code does not have to take place even if the data changes considerably in the future. 

WPF has this really convenient class called XMLDataProvider that allows you to use XPath to bind UI to Xml.  This is really nice but only for read-only data.  You can Bind a WPF View two ways with XMLDataProvider and edit the Xml but it's not conformant enough for a production piece of user interface since it's hard to validate inputs. Contrast this with something like a .Net DependencyProperty with meta data and a CoerceValue callback and you will see two very distinct poles of data integrity.

Also note that .Net gives you a lot of tools to control the Serialization/De-Serialization process in the System.Xml.Serialization namespace. Specifically check these attributes out.

Remember only public fields and their associated backing fields ( if any ) are serialized with the XmlFormatter. Now check out this cool stuff when you are interested in serializing a large collection like an Address Book and you want to show detailed progress.