Re: Binary Infosets

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

MD> 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.

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.

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.
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.
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.

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.

MD>    or c) the gap between (maybe parsed, but otherwise not much
MD>    changed) X(HTML) and text display operations and the gap between
MD>    SVG and graphics display operations is bigger,...)

There is that, too. Its possible to imagine a (non-script-enabled,
non-CSS, minimally interactive) treeless display engine than
constructs display lists and structural snippets on the fly and throws
away the input document. As soon as you add propogation of events,
inheritance of properties, cascading, and DOMaccess then you need to
store all the strings and all the spaces *as well as* your display
structure. It becomes too big. Binary infoset is one way to transmit
the same information more efficiently in terms of storage space
consumed while active on the client, and while less desirable than
mobile devices that have larger memory, is ore desirable than devices
that transmt mere binary display lists (graphics engine commands)
with the XML totally unavailable behind a server somewhere.

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

With respect, Martin, it could be that the mobile community has
learned and is trying to solve the problem a better way but that the
problem has not conveniently evaporated in the interim; it could also
be that you need to look more closely at the current work before
coming to a snap judgement.

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.


-- 
 Chris                            mailto:chris@w3.org

Received on Monday, 14 October 2002 02:13:03 UTC