

Review of binary use cases

From: Norman Walsh <Norman.Walsh@Sun.COM>
Date: Thu, 31 Mar 2005 12:32:51 -0500
Message-id: <8764z7g1q4.fsf@nwalsh.com>
As promised, I read through the binary use cases document. Alas, I
don't feel much the wiser for having done so. The document lays out a
series of use cases and explains why each case requires binary XML.
For the use cases I understand, the arguments seem to have merit,
though none of them left me feeling really persuaded.

A few specific comments:

In 3.6 they argue for a binary encoding for "electronic documents"
on the basis that documents contain images and fonts and video and
such and because non-linear navigation is required.

I am *utterly* unmoved by the arguments, though perhaps personal bias
plays a part. The long-lived nature of documents makes a textual
encoding of the information an overwhelmingly superior choice, in my
opinion. I'll gamble that my textual XML documents will be readable,
at least by humans, in 1,000 years. I won't take that gamble with
*any* binary format.

I don't know why they seem to feel that an index requires a binary
format. I'm pretty sure that the amount of cleverness necessary to put
an index at the beginning of a text document is managable. I'm also
not convinced that "update" requires a binary format, though I concede
that the challenges are significant.

And I also don't believe the assertion that text "represent[s] a
decreasing fraction of all electronic documents".

In fact there were other assertions, like this one:

   A compact binary format is likely to be intermediate in size
   between a zlib compressed XML stanza and the original XML, while
   retaining high processing speed.

that seem reasonable on the surface but that I'd be reluctant to
accept as fact without some measurements to back them up. But maybe
that's in one of the other documents.

                                        Be seeing you,

recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution is prohibited.
reply email and destroy all copies of the original message.

Received on Thursday, 31 March 2005 17:33:04 UTC
