I learned something really interesting in the Indigo talk that I did manage to go to -- although Indigo is very closely tied to the logical model of the XML Infoset (basically it assumes XML 1.0 + Namespaces as the logical lingua franca), there's no requirement for that logical model to be persisted as a text-based stream of UTF-8 encoded characters. Indigo is actually wire-format agnostic, relying on a formatting mechanism similar to that of .NET Remoting's infrastructure to handle reading and writing an infoset to the wire.

I would imagine that most Indigo scenarios would use the standard UTF-8 encoded XML wire format for communication. This text-based representation is great for readability and interoperability. However, there are some downsides to this wire format -- it's expensive to parse, costly to transmit, and is a generally inefficient representation. There are times when these characteristics are not desirable.

For example, say you're deploying two services that coexist within the same AppDomain. In this case, it makes no sense to use UTF-8 encoded XML as the communication format -- it's just too expensive, and you don't need the benefits of readability and interoperability that the formats provide. It's specifically for cases like this -- where performance trumps interop -- that Indigo's support for custom wire formats become useful.

The specifics of this extensibility point won't be covered until Thursday, but I do know that Whidbey will support some sort of binary XML representation. This binary form will be isomorphic to regular text-encoded XML (and probably can be readily converted to text for debugging purposes), but has a smaller memory footprint and parses faster than text.

There are other uses for binary XML inside outside of Indigo. I think portions of the Avalon stack use a custom binary representation of their XML vocabulary to minimize download times for tricke-feed applications (which are apparently now called "Drizzle Download"). If I remember correctly, this new format is called BAML (binary Application Markup Lanugage)...

It will be interesting to see how the decision to support binary XML will be taken up by the community. There's already been a lot of debate about this -- I imagine that the "XMLness" of binary XML will continue to be debated for some time.