Re: [binaryXML-30] Binary XML problem statement.

Chris,
I ran across this thread in the www-tag public archives. As the author of
one of the references you cite, [5] XML Sizing and Compression Study for
Military Wireless Data, I would point out that the paper and presentation
can be found at the below links (I think they are publicly available, if not
contact me for distribution). It compares approaches (XMill, MPEG-7, gzip,
ASN.1-PER, and WBXML) against a sample binary message set.

http://www.idealliance.org/papers/xml02/dx_xml02/index/author/ed8776ca16026c
570dea4333a9.html
http://www.idealliance.org/papers/xml02/slides/winkowski/winkowski.pdf

This subject and debate is of great interest as it parallels our internal
discussions. My own view is when it comes to optimizations one size does not
fit all. That said, some standardization or recognition of standard
solutions would be a step forward. In the best of worlds, I would love to
use XML Schema for my message designs and at the same time take advantage of
alternate optimized encodings that can be applied to transform the syntax
for transmission, storage, or direct machine-to-machine communication when
presentation is not an issue. The message specific encoder/decoder would be
derived directly from the XML Schema by way of standard functions. In this
way only the schema declarations need to be transmitted in plain text.
Recipients would be able to automatically derive the decoder based on the
schema and the encoder function used.

Oh, and just like zip there may be a choice of algorithms applied based on
analysis of the input. We found for larger messages sets redundancy based
compression outweighed optimized binary serialization of fields and
structure.

I look forward to the public deliberations. I've address the list in this
message but am not subscribed so don't know if it will bounce back. If so
please forward as you see fit.

- Dan

- Daniel G. Winkowski
MITRE, 1 Enterprise Parkway, Suite 100, Hampton VA 23666

Received on Tuesday, 4 March 2003 18:05:12 UTC