Re: Binary Infosets

Martin Duerst wrote:
> At 23:58 02/10/09 +0200, Chris Lilley wrote:
>> 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.

I agree that WAP-style encodings don't fly well, and that there is a 
great number of situations where plain (or gzip'ed) XHTML works 
perfectly well. As Chris pointed out WAP-style approaches are 
unextensible, and that imho makes them pretty much anti-Web and anti-XML.

There are however places which want (or are strongly encouraged) to use 
XML but that suffer from severe processing and memory constraints. This 
covers part of the mobile community, as well as several "small devices" 
communities (eg numeric TV and radio) or even audio-video communities 
that include desktop systems in their targets (that's part of what 
MPEG-7 was for).

The reason I was curious as to whether the TAG had already an opinion on 
such matters is because such binarisation approaches* are being deployed 
currently or in the very short term, and in a fair number of cases I 
think rightly so (otherwise I'd have picked a job elsewhere ;). What's 
more, they are not limited to "strange" environments such as broadcast 
carrousels but also concern Web environments. Part of my job is to make 
sure that binary infosets play well within the Web (overall it works 
rather well imho, but there are issues to iron out).

> For graphics, the mobile community seems to favor something binary.

I think that opinions are more varied than you think. In truth, few 
people truly favour binarisation per se because they know it's extra 
work compared to just sending the XML. But most appear to recognize this 
as a necessity (and of course even more so in the smaller devices area).

> I haven't been able to figure out yet whether this is because:
> 
> - The mobile community hasn't learned and is falling in the same
>   trap as they did last time.

I think part of the community has learnt. Seeing some of the scary specs 
for binarisation that I've seen however, I am not totally convinced that 
they have all learnt from WAP's mistakes. I certainly hope they do.

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

That's interesting, I've received feedback that is the exact opposite 
(ie people favouring bit-level, irrespective of the domain). I'd be 
interested in hearing (perhaps off-list) about those other echoes.

Cheers,


* I say "binarisation" instead of compression because those approaches 
also tend to want to decrease memory usage and processing time (as 
opposed to just bandwidth), and sometimes include things like lazy 
loading, remote update, indexation, streaming, etc.

-- 
Robin Berjon <robin.berjon@expway.fr>
Research Engineer, Expway
7FC0 6F5F D864 EFB8 08CE  8E74 58E6 D5DB 4889 2488

Received on Monday, 14 October 2002 10:18:43 UTC