Marc Clifton seems a bit frustrated that XAML isn't the end all be all serialization engine. XAML is a general purpose markup format, but in Longhorn there will be a new general purpose serialization engine.

XAML was designed to be a compromise markup format, that balanced the toolability and readability aspects of a markup. You can think of HTML as a markup that was squarely designed to be readable, but not very toolable. SOAP on the other hand is very toolable, but almost impossible to read. In the design of XAML we constantly walk the line between the two. XAML has support for inline code, customer parser extensions, and multiple representations of the same structure.

In Longhorn there will be a new serialization engine in WinFX. The goal of this new engine is to unify the scenarios addressed by the XmlSerializer, SoapFormatter, and BinaryFormatter.  This engine (residing in the existing System.Runtime.Serialization namespace) will allow serialization and deserialization of any CLR object graph (graph is a carefully chosen word here) to a variety of different formats (including XML and your own custom ones, if you wish).

Lets compare the two methods:

XAML

• Objects must conform to a specific contract (public properties, empty public constructor)
• Extensions done through interfaces on objects (in other words you must load CLR types to serialize or deserialize the format)
• Only supports object trees (no graph support)

System.Runtime.Serialization

• Any object regardless of shape can be serialized (properties, fields, events, private or public data)
  Extensions done through declarative metadata (DataContract attribute), which means you only need metadata or schema to parse
• Graph or tree structure

XAML is designed to be more of a mix between a document and a programming language (something like ASP.NET's markup) with a fixed grammar where as System.Serialization is designed to consume and produce arbitrary XML and CLR graphs.