Christophe Rhodes  <csr21@cam.ac.uk> wrote:
+---------------
| "John Thingstad" <john.thingstad@chello.no> writes:
| > I think it is more a question of being old enough to see that doing
| > the same old thing (storing data) with more sluggis[h] data retrival
| > and taking 4 times the room is not progress.
| 
| How do you think error-correcting codes work?  How would you
| characterize the speed of retrieval and space requirements of such
| codes?
+---------------

1. A heck of a lot more efficient than XML!!  You'd have to be dealing
   with a really *high* error rate -- multiple percent per byte! -- to
   need an error correction code use equivalent overhead to XML's bloat!
   [E.g., a rate-3/4 or rate-1/2 convolutional code.] And even at that,
   you'd be *getting* something for your overhead, namely, significant
   error *correction*. XML's trailing brackets provide at most some minor
   error *detection*, not much better than an extra parity bit per element.

2. Practical error-correcting codes have *less* overhead than XML!
   For example, a Reed-Solomon code capable of *correcting* up to
   three bytes in error anywhere within each XML element would only
   cost 7 bytes per element (for elements <248 bytes long). Compare
   that to the sum of the lengths of typical XML opening & closing tags!

3. But all that is moot, since XML doesn't provide any error correction!


-Rob

-----
Rob Warnock			<rpw3@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607