OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: [xml-dev] Why XML for Messaging?

[ Lists Home | Date Index | Thread Index ]

Microsoft's position has been consistent. We don't think there is a single binary standard that will satisfy the myriad use cases of XML* and more importantly we worry that a 'standardized' binary XML format by an organization like the W3C will lead to fragmentation of the interoperability story of XML. 
 
* We just announced that the next version of Office will use compressed XML as its primary file format. Although this works fine for Office, it would not work fine for other products at Microsoft. Similarly I doubt that Sun's fast infoset would be as satisfactory an option for storing office documents. 
 
-- 
PITHY WORDS OF WISDOM
A meeting is an event at which the minutes are kept and the hours are lost. 

________________________________

From: Bullard, Claude L (Len) [mailto:len.bullard@intergraph.com]
Sent: Thu 6/2/2005 7:41 AM
To: Dare Obasanjo
Cc: xml-dev@lists.xml.org
Subject: RE: [xml-dev] Why XML for Messaging?



Because Sun goes to the trouble of getting an
international standard for it.  Microsoft is
fighting that idea.

"Paoli's passion for XML and documents shined through the entire talk,
especially two of the final points. He spoke out against binary XML, simply
saying "No, please," and concluded with a prediction: In 2010 75% of new
documents worldwide will be created in XML."
http://www.xml.com/pub/a/2005/06/01/deviant.html

The business models of the customers prefer
standards.  Paoli's tactic ultimately means no binaries
unless they are Microsoft-framework supported.
Yes, we can do what you suggest.   Why bother?
We can do that with FastInfoset and be both
standard and indemnified. Note that this isn't
just Microsoft.  IBM is fighting it, the XML
community is fighting it, everyone I suspect
but the graphics folks and other performance
bound implementors.

Using big vendor frameworks in situations like
this is like dating a vampire: the vampire is 
sophisticated, rich, slick, and hey it can fly but 
just before the light begins to dawn on you,
it puts the bite on you and now you too have to
live in the shadows.

My advice to the middle tier vendors:  instead
of accepting the vampire's embrace, implement
the most framework and platform independent
means you have even if that means returning to
C and C++ and taking on the costs of creating
libraries.  The short term productivity benefits
of using the frameworks are becoming riskier.
The independence that XML provided is being
replaced by dependence on the libraries and
this is far riskier to your marketshare as it
enables the platform provider to invade and
possess your market while you can't guarantee
performance.   Don't give up your
power to negotiate which is ultimately your
willingness to walk away from the table.

len

(also speaking solely for myself and not
my employer)


From: Dare Obasanjo [mailto:dareo@microsoft.com]

> Because where one wants to use XML machinery without XML
> syntax on the wire, one has to have the infrastructure and if
> that means getting it from Sun, so be it.  MS doesn't get to
> play in that market.

Then we are now in the infoset permathread.  Sure anyone can come up
with a framework that enables passing around binary representations of
XML. APIs like SAX and the .NET Framework's XmlReader can be implemented
over binary streams as well as text XML.

I'm not sure where the idea that this is technology exclusive to Sun and
not Microsoft comes from. Can you clarify?






 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS