Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Binary XML Permathread, iteration N+1 - was Re: Python and JSO
 On 8/26/05, Bullard, Claude L (Len) <len.bullard@i...> wrote: > Microsoft has to take the credit and > the blame for what is about to happen. Speeding up XML > and compressing the payloads is a big deal. Those who > don't think XML Binary is going to happen are putting > rocks in a river that will simply flow around them. Just in case this was partially directed to me (I've been pushing the MS party line on the W3C lists on this topic), let me make one thing perfectly clear :-) There's no doubt that speeding up XML and compressing payloads is a big deal in some important scenarios. Binary XML is happening, here, at all the big vendors AFAIK, at W3C, and in a bunch of small innovators. There are three big questions that we don't think have good answers so far, but should be answered before a binary XML format is standardized: - Is this technology ready for widepread standardization? I lean toward "no", because a) there is a tradeoff between speeding up XML and compressing the payload, and different use cases would adjust this tradeoff differently and b) we are as an industry learning an awful lot about how to do this better, so freezing the technology at the current state is short-sighted. - Can a single "efficient XML interchange" (aka EXI, "binary XML" is no longer au courant) Recommendation hit a good 80/20 point across the major use cases? I'm keeping an open mind on that, but I fear that many major stakeholders want a different 20%. - Can EXI be standardized without undermining XML's basic value proposition of universal interoperability? That's probably the most controversial. Obviously a lot of people who post here have been shouting "NO!". The EXI advocates seem to be saying "sure, no problem, but let's not worry about that little detail now, trust us to get it right in the spec". I tend to think that this could be done in principle and over time, but I'm not sure it can be done in a way that works with XML 1.0. Overloading the encoding declaration might be possible, but some EXI advocates shudder at the "huge" 32-character overhead and XML text advocates point out that this would make it harder to distingish the character-level encoding from the infoset-level encoding, e.g. an EXI-encoded document in UTF-8 from an EXI-encoded document in ISO 8859. So, I don't know how an EXI Recommendation in the next couple of years could avoid disrupting XML interoperability for the existing installed base, although I appreciate the argument that it would extend XML's reach to new environments that can't use XML until it is more efficient. 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
