[
Lists Home |
Date Index |
Thread Index
]
Hi Mike,
>
> So, my somewhat ignorant question is: why would these WBXML folks go to
> the trouble of defining yet another compression scheme for wireless XML?
> Aren't the usual compression techniques available in wireless
> toolkits/operating systems? Can XML-specific compression schemes be
> implemented in significantly less space than gzip (or LZW, or some other
> widely deployed scheme)? Finally, I thought the WAP Forum had learned its
> lesson about diverging from standard practice (de facto or otherwise) on
> the internet, since the wireless infrastructure will not lag TOO far
> behind the rest of the internet, but it takes quite a bit of time to
> deploy enough WAP technology to make it worthwhile for enough people to
> support it to be worthwhile ....
>
Speaking from the technical angle ...
Compression strategies can take 2 basic forms,
(please pardon my generalization as its far from these 2 simplistic forms)
Code/Table based encoding. This essentially assumes that both the
encoder and decoder has an intimate knowledge of the transmitted code.
Reducing information content to code is very efficient. For instance,
the number 1234567890 which is 10 bytes long (or 20 bytes for UCS2),
can be represented by a 32-bit long which is just 4 bytes. Or an
encoding scheme like reducing UCS2 to UTF-8. Both the encoder and
decoder knows the "format" in advance. Take it as
"synchronized encoding" if you like. Its fast at both ends.
GZIP, Huffman, LZW, (1D/2D codecs), on the other hand, makes use
of statistical redundancy to do its job and has a typical overhead.
i.e. if your data is very small, compression could actually inflate the
data size rather than reduce it. Such lossless encoding is also dependant
on how much redundancy the data actually contain. Data that contains
loads of repeats would benefit from such compression. (for instance
whitespace may be encoded with just 1 bit - statistically speaking it
will go below 1 bit per symbol)
For WBXML, yes, I can see value in the effort because wireless data
packets are expected to be small, LZW/Huffman encodings might
not be as effective or may not even work. However, with 3G and
larger wireless bandwidth offerings, its value may (will) diminish.
rgds,
Kuan Hui
|
