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


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] Re: [ubl-dev] Top 10 uses of XML in 2007

Joining this thread a little out of context, I think there's a point about 
Binary XML that's worth repeating.  I know very few people knowledgeable 
in the subject who don't think some forms of Binary XML are needed in some 
places for important reasons.  In fact, there is no question that various 
forms of binary XML are being used internally by a variety of XML 
implementations, including for example various DOMs, the on disk format of 
certain XML-enabled databases such as IBM's DB2 Viper, etc.   I think many 
people are also willing to acknowledge that the blessing of some new 
Binary format as an "XML Standard" raises interoperability concerns, at 
least insofar as the millions of already deployed XML implementations will 
not read files or streams in the new Binary format.   The key question is 
not whether  "The vendors who really can't live with XML won't be able to 
stomach binary XML either.".

The more subtle questions are whether a single binary technology can meet 
a sufficient range of use cases to justify whatever disruption there will 
be to interoperability.  While DB2 Viper, for example, has an on-disk XML 
format that is exceptionally well optimized for its requirements for data 
storage and query, it's not what you'd want as the container format for an 
XML office document.  There are a number of XML Office Document formats 
being promoted, both of which as far as I know happen to use zip 
technology as their container and compression format.  This gives certain 
desirable characteristics, including the ability for users to employ 
widely available zip tools to manipulate the files.  Unfortunately, this 
is probably not the binary format you'd want for high performance Web 
Services.   Furthermore, in situations like Web services, a lot of the 
really interesting gains come not just from compressing XML, but from 
realizing that multiple XML documents from the same or similar 
vocabularies are to be sent over the same connection.  In this case, you 
can often share dictionaries and other metadata across multiple compressed 
documents, but in that sense what you're offering is not so much a format 
for standalone binary XML documents, but a format for a compressed stream 
of similar XML documents. 

The W3C EXI workgroup seems to be optimistic that a sweet spot can be 
found, one for which they believe the advantages of the technology they 
will (likely) propose will justify a W3C Recommendation.  Not speaking for 
my employer, IBM, but for myself:  I've been publicly skeptical for a 
number of years, since I first gave a position paper at the W3C workshop 
on the subject.  Obviously, reasonable people can disagree on this.  It's 
a tradeoff.  I don't think the right answer is likely to relate very much 
to "who can stomach XML", because the marketplace is telling us where XML 
is useful and where not.  I don't think the question is whether there will 
be binary XML, because there is already binary XML.  In fact, there are 
already lots of binary XMLs, and for some good reasons.  The question will 
be whether to anoint one such format as a general purpose standard. 

Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

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

Copyright 1993-2007 XML.org. This site is hosted by OASIS