[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
- From: noah_mendelsohn@us.ibm.com
- To: "Stephen Green" <stephengreenubl@gmail.com>
- Date: Mon, 19 Feb 2007 14:58:18 -0500
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
1-617-693-4036
--------------------------------------
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]