Cart
[Home] [By Thread] [By Date] [Recent Entries]
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] |
