[
Lists Home |
Date Index |
Thread Index
]
From David Starr:
>
> > From: Mike Champion [mailto:mc@xegesis.org]
>
> >So, my somewhat ignorant question is: why would these WBXML folks go to
> >the trouble of defining yet another compression scheme for wireless XML?
>
> There are both theoretical and practical reasons for reconsidering
> compression in wireless environments. All have to do with the interaction
> between compression and error correction. Virtually all digital wireless
> systems employ some form of Reed-Solomon based forward error correction.
> For those not familiar, this involves coding a field of n information
> elements as n+p information elements such that when those n+p elements are
> transmitted if some number greater than n elements arrive, then the
message
> can be reconstructed. Almost all systems employ this coding over bit
> fields. And some wireless applications employ it over packet fields in
> addition to whatever bit level correction is used.
>
> It has been observed (and I believe proved as well) that for transmissions
> on a randomly noisy channel, that transmission with forward error
correction
> is closer to the Shannon limit for that noisy channel. In other words one
> comes closer to the total information carrying capacity of the channel by
> adding information, when that channel is noisy!
>
> Compression on a clear channel assumes that by coding using a fewer bits
is
> optimal. But in the noisy wireless environment we've demonstrated a case
> where more bits is more efficient (in the information theoretical sense).
> Compression and error correction are often treated as discrete steps. One
> might find greater overall efficiencies if these bit-adding, and
> bit-reducing steps were treated holistically.
>
> On the practical side, there are several different types of Reed-Solomon
> error correction. Some will guarantee to deliver a correct message or
fail.
> Others make a best effort, but will indicate whether a field might be
> incorrect. Applications that can tolerate some loss of data, or require
as
> much of a message as it can reliably receive, might not want a compression
> method that require the entire stream to reliably decode it.
>
> That's a long answer to why one would want to reconsider compression for
> wireless. From a not particularly thorough reading of WBXML, I'm not sure
> that it's trying to deal with these issues. Maybe it should be.
>
>
No, WBXML does not deal with the issue of noisy wireless channels. It
tokenizes XML to make the document smaller and removing the need for an XML
tokenizer (part of the parser) in the mobile phone. There is really nothing
"wireless" about WBXML.
--
Peter Stark
|
