Re: Binary Infosets

Hello Chris,

At 08:12 02/10/14 +0200, Chris Lilley wrote:

>On Saturday, October 12, 2002, 9:44:22 AM, Martin wrote:

>MD> For (X)HTML, the consensus in the mobile community seems to be that
>MD> the WAP-style binary compression/infoset was the wrong way to go;
>MD> transmitting plain (X)HTML is no big problem.
>
>Those are three separate statements, and I agree with two and disagree
>with one.

I think the way you split it up isn't exactly the way I wanted to
say it.

>1) WAP-style (fixed, enumerated tokens, non-adapatable, impossible to add
>another element or attribute or namespace) compression was not a good
>idea as a way forward. Agreed.

Agreed in the long term. For what WAP wanted to do, it wasn't too bad.
But it was just that compression turned out to not be necessary.


>2) All other forms of binary infoset (incluuding adaptive methods that
>allow arbitrary XML content and mixing of multiple namespaces) are
>thus also a bad idea. Diasagree. They might be a bad idea or a good
>idea, insifficiently studied as yet.

I didn't say that. I may have alluded something in this direction
below, but above, I didn't say anything like this.


>3) XHTML documents, particularly ones specially made for mobile use,
>are short so compression pain produces little gain. Agreed.
>
>MD> For graphics, the mobile community seems to favor something binary.
>MD> I haven't been able to figure out yet whether this is because:
>
>MD> - Graphics is in some way different (e.g. a) the average Web page
>MD>    size that makes sense on a mobile phone is much smaller than
>MD>    the average amount of data needed for graphics (in particular
>MD>    with animation),
>
>That aspect is true, yes.

Do we have any good grip on this, any kinds of numbers?


>MD> or b) SVG compresses better than (X)HTML
>MD>    (more markup, more sections with low entropy such as paths),
>
>SVG is indeed designed to compress well.

Sorry, I was unclear here. What I wanted to say is that maybe
it is easier (in the sense of higher compression rates) to compress
SVG further into a binary format than to do the same with (X)HTML.
I do not know whether this is true, but there could be various
reasons for this:
- More markup/styling for SVG than for (X)HTML, and markup/styling
   is usually easier to compress than data.
- Data (e.g. path data, which is mostly numbers plus a few letters)
   has a higher redundancy.

>MD> Also, I'm confused because I have seen strong indications
>MD> from the mobile community that they don't want to go down
>MD> to the bit level for compression  (WAP binary xml didn't;
>MD> gzip and friends of course do) because this implies too
>MD> much processing, but the compression proposals
>MD> I have seen for SVG mostly go to the bit level (e.g.
>MD> using a number of bits rather than a byte to indicate
>MD> the type of an element).
>
>The SVG Mobile community is part of the Mobile community, and often
>involves the same organizations, so your comment does not really hold
>water.

I don't understand this. If I point out that there are different
opinions or different approaches, then my comments don't hold
water if you can show that these different opinions come from
people in the same organizations?

It would be more interesting to understand
what the tradeoffs are for the various approaches.

Regards,    Martin.

Received on Wednesday, 16 October 2002 00:22:28 UTC