Re: Binary Infosets

At 23:58 02/10/09 +0200, Chris Lilley wrote:
>As you can tell from the, uh, "terse" writing style this section is
>not mature at all. It is mainly a framework in which to slot
>existing, in-progress questions and also attempts to anticipate some
>likely future questions.
>The part you cite falls into the latter category. Some mobile
>implementors are working on this, for example the CVG format from 3GPP
>or nva from Sharp or, as you note, the expway stuff. Equally, there
>seems to be a strong sentiment from the (mainly desktop) developers
>that there should only be one serialization of the infoset.
>And yet, we tell the mobile folks that they should not use WAP and
>whatever but should use XHTML Basic and SMIL Basic and SVG Tinty and
>so forth. And they tell us that the http-level binary compression,
>which works well on the desktop, does not work well for them because
>the main issue is storage efficiency on the client while being used.

For (X)HTML, the consensus in the mobile community seems to be that
the WAP-style binary compression/infoset was the wrong way to go;
transmitting plain (X)HTML is no big problem.

For graphics, the mobile community seems to favor something binary.
I haven't been able to figure out yet whether this is because:

- Graphics is in some way different (e.g. a) the average Web page
   size that makes sense on a mobile phone is much smaller than
   the average amount of data needed for graphics (in particular
   with animation), or b) SVG compresses better than (X)HTML
   (more markup, more sections with low entropy such as paths),
   or c) the gap between (maybe parsed, but otherwise not much
   changed) X(HTML) and text display operations and the gap between
   SVG and graphics display operations is bigger,...)

- The mobile community hasn't learned and is falling in the same
   trap as they did last time.

Also, I'm confused because I have seen strong indications
from the mobile community that they don't want to go down
to the bit level for compression  (WAP binary xml didn't;
gzip and friends of course do) because this implies too
much processing, but the compression proposals
I have seen for SVG mostly go to the bit level (e.g.
using a number of bits rather than a byte to indicate
the type of an element).

Regards,    Martin.

Received on Saturday, 12 October 2002 03:44:47 UTC