OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Binary XML - summary of discussion to date



From: Al B. Snell <alaric@alaric-snell.com>

>To date:

Can I say I think it is quite bad form to state personal opinions as a
"summary" of a discussion.  In particular, the #4

>4) Regarding human-readability; if the format is ubiquitious like JPEG or
>ZIP or gzip, then there will be tools to view them, just like there are
>tools to examine zip files and so on. The human readability argument
>really only tells us that non-public proprietary standards are bad; it,
>again, is not really about text vs. binary. The fact that text viewers are
>very widely available already is a plus point for textual encoding, but
>it's probably of similar magnitude to the speed gain of binary encoding in
>many applications :-)

This is utterly cart before the horse.  Things succeed if they fit into
existing technical infrastructure: the WWW fits on top of the Internet, XML
fits on top of text and on top of existing APIs for programming languages
(e.g. printf() in C).  A binary format may have a chance of succeeding if it
fits on top of XML and it has some significant niche use better than
encryption and ASN.1.

There are *not* other tools.  There is not another MIME branch like text/*
which
defaults to anything.  Text can be edited as text: grepped, searched,
sorted, which gives a different view of the data from tree-systems. It
starts from where we are.

"Tools" means tools in English at the start. So a binary format re-inforces
the center-periphery status quo: it adds another hurdle for foreigners.

Cheers
Rick Jelliffe