RE: "Binary XML" proposals

[Al Snell <alaric@alaric-snell.com>]

On Wed, 11 Apr 2001, Miles Sabin wrote:

> > Doesn't matter what the paper spec says if it has no teeth,
> > because the real spec is the Vendor X implementation.
> 
> I don't disagree ... but I don't see how this is supposed to
> help differentiate between text and binary.

The "text vs. binary" debate often fails to compare like with like...

People compare:

<person>
<name>Alaric</name>
<age>43</age>
</person>

with:

Alaric[00][2B]

 - where [x] is the byte with value X in hex

But the binary encoding really encodes the same data as:

Alaric,43

does in a textual CSV file. Which isn't very self describing, no - but
that's not the binary's fault.

People should compare:

<person>
 <name>Alaric</name>
 <age>43</age>
</person>

with something like:

[01][06]person[01][04]name[00][06]Alaric[02][01][03]age[04][2B][03][03]

...which doesn't look so good at first glance, I agree, but that's because
you're viewing this with a text viewer; it's easy to remember and not too
hard to figure out that [01][length]string is an open element tag,
[00][length]string is a CDATA, [03] is a close tag, [04] means a one-byte
integer...

And that's only if the binary format doesn't become and established
standard with nice editors and viewers everywhere. My example above is
much more readable than a PNG file:

00000000  89 50 4e 47 0d 0a 1a 0a  00 00 00 0d 49 48 44 52 |.PNG........IHDR|
00000010  00 00 00 0c 00 00 00 0c  08 00 00 00 00 73 1e 03 |.............s..|
00000020  3b 00 00 00 63 49 44 41  54 78 da 55 8e b1 0d c0 |;...cIDATx.U....|
00000030  30 08 04 bf a4 f4 1a 2e  29 bd 42 66 a3 74 e9 36 |0.......).Bf.t.6|
00000040  23 64 8d ac c1 08 94 04  48 a2 28 14 f0 27 a4 ff |#d......H.(..'..|
00000050  87 bb cd d1 da 58 e6 0e  57 06 a8 03 ac 0e 0b 0d |.....X..W.......|
00000060  39 63 b1 41 80 4d 2d 21  64 3e b0 17 30 28 cf 2a |9c.A.M-!d>..0(.*|
00000070  a0 3f f0 07 9c 06 2f c8  63 7d dc d6 ae 1d 35 19 |.?..../.c}....5.|
00000080  1a 75 84 89 c6 8c 3a 17  c0 78 2c 16 ec c1 54 b4 |.u....:..x,...T.|
00000090  00 00 00 48 74 45 58 74  53 6f 66 74 77 61 72 65 |...HtEXtSoftware|
000000a0  00 40 28 23 29 49 6d 61  67 65 4d 61 67 69 63 6b |.@(#)ImageMagick|
000000b0  20 35 2e 31 2e 31 20 30  30 2f 30 32 2f 30 31 20 | 5.1.1 00/02/01 |
000000c0  51 3a 31 36 20 63 72 69  73 74 79 40 6d 79 73 74 |Q:16 cristy@myst|
000000d0  69 63 2e 65 73 2e 64 75  70 6f 6e 74 2e 63 6f 6d |ic.es.dupont.com|
000000e0  0e 4b 11 b8 00 00 00 2a  74 45 58 74 53 69 67 6e |.K.....*tEXtSign|
000000f0  61 74 75 72 65 00 37 62  63 65 65 36 62 61 63 34 |ature.7bcee6bac4|
00000100  35 33 61 39 37 38 30 65  39 62 30 62 64 62 35 66 |53a9780e9b0bdb5f|
00000110  64 32 34 66 36 31 a6 8b  29 98 00 00 00 00 49 45 |d24f61..).....IE|
00000120  4e 44 ae 42 60 82                                |ND.B`.|
00000126

...although even that is moderately clear; the image header, data, a tEXt
chunks are easy to see, as is the IEND chunk... figuring out what's in the
IHDR or IDAT chunks relies on reading the spec, but hey, it's an RFC...

ABS

-- 
                               Alaric B. Snell
 http://www.alaric-snell.com/  http://RFC.net/  http://www.warhead.org.uk/
   Any sufficiently advanced technology can be emulated in software