What is Microsoft's experience with Efficient XML Interchange solutions?

Mike Champion states on his blog:

“For example, Microsoft's opposition to Binary XML standardization is based on actual experience wrestling with the different ways in which XML is inefficient and in analyzing how to improve that inside various XML-based products in ways that wouldn't impact interoperability. I suppose that to many on the outside it looks like stasis -- we recognize the XML is inefficient but can't endorse an industry-wide attempt to improve efficiency; from the inside I see the analysis -- the cost of XML's inefficiency seldom outweighs the benefit of data interoperability, and when it does, the optimizations for one product domain haven't been useful in another.”

I asked before (IIRC this will be the third time) what this experience is but have yet to receive a satisfactory answer. It would be great if some people from Microsoft could explain what difficulties they have encountered. I am no way implying that Microsoft has not encountered very real issues. Stating that there are problems is fine but such statements need to be backed up with reasons for these problems otherwise it is difficult to move the debate forward.

Two such proprietary binary formats developed by Microsoft are:

  1. the WCFs binary messing encoding, for the efficient encoding of SOAP message infosets; and

  2. the BAML binary encoding (see here and here), for the efficient encoding of XAML infosets.

What are the differences between these encodings that make it difficult for them to share a common encoding framework?

Comments:

I responded in as much detail as I can on the W3C member-only mailing list setup to discuss this issue. I don't know enough about BAML to say anything. I did discuss the fact that the binary encodings for office documents, SOAP messages, and XML DBMS client-engine communication have very different constraints, and thus different solutions.

I don't want to worry about what is and is not public knowledge about the MS formats, so let's talk about OASIS ODF and FAST Infoset as surrogates. The fact that both have standard representations as XML is somewhat beside the point/ ZIP works fine for StarOffice, right?, but not for the FAST Infoset use cases (which I believe needs to handle short messages and needs more efficient compression than the ZIP algorithm). Could FAST Infoset replace ZIP in StarOffice / ODF? I suppose, but you wouldn't get as good compression, you wouldn't get ZIP's hierarchical archiving capability out of the box, and you would get better performance but that's not a serious bottleneck for office document use cases.

So, how would you answer the question of what differences between ODF and FAST Infoset make it difficult for them to share a common encoding framework? I'll guess the idea of combining them wouldn't get far enough to generate hard data. That's more or less what the situation is with MS Office, WCF, and SQL Server. We've actuually done a bit more prototyping (I don't think it would be prudent to elaborate) that is somewhat technically interesting, but nowhere near exciting enough to push back on the consensus that there is no sweet spot that offers both commonality/interoperablity and a significant improvement in efficiency over XML.

Posted by Mike Champion on October 21, 2005 at 11:25 PM CEST #

Post a Comment:
  • HTML Syntax: NOT allowed
About

sandoz

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today