Comments on XBC Use Cases

I agreed to review the XML Binary Characterization Use Cases document
for the XML Core WG. I realize I sent my notes to the Core WG but
neglected to send them here. FYI, here are my notes, amended slightly
to better suit this context. (These are my notes only, I do not claim
that they represent the consensus of the Core WG.)

Alas, I don't feel much the wiser for having read the Use Cases
document. 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:

Section 3.6 argues 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 make that gamble with
*any* binary format. XML already has good mechanisms for dealing with
images and video (linking) and fonts (stylesheets, either embedded or
external, that separate presentation from content). The fact that
there's no good packaging specification to bind all these components
together into a single unit is a problem, but not one that requires
binary XML to solve.

I don't know why the document states 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". If that is true, I
would like to see the evidence that supports it.

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,
                                          norm

-- 
Norman.Walsh@Sun.COM / XML Standards Architect / Sun Microsystems, Inc.
NOTICE: This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.