[
Lists Home |
Date Index |
Thread Index
]
Indeed, WBXML content is sent on protocol layers waaaaaaay above the
wireless protocols (of which I have a very lightweight knowledge since I
won't need to know anything about them in centuries of WAP coding).
There is no possibility for a synergy between the low level wireless layers
and the high-level applicative layers, so WBXML does not address the issue
of compression vs {n,p} encodings. If you don't have access to the error
correcting encodings, then your objective is to be as compact as possible.
Maybe putting some compression together with error correction in the same
layer is an interesting thing, however the current WAP over GSM architecture
does not allow this. AFAIK, it's the same with voice data, as the voice
compression/decompression operate above the transport and error correction
layer.
Regards,
Nicolas
>-----Message d'origine-----
>De : Peter Stark [mailto:pstark@telia.com]
>Envoyé : mercredi 13 mars 2002 08:12
>À : xml-dev@lists.xml.org
>Objet : Re: [xml-dev] Compression and wireless XML
>
>
>>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
>
>
>-----------------------------------------------------------------
>The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
>initiative of OASIS <http://www.oasis-open.org>
>
>The list archives are at http://lists.xml.org/archives/xml-dev/
>
>To subscribe or unsubscribe from this list use the subscription
>manager: <http://lists.xml.org/ob/adm.pl>
>
|
