Re: Binary Infosets

Martin Duerst wrote:
> Well, binary WAP was that way, and that was done on purpose.
> And if you want to use the same data layout on the device as
> you got over the wire, and don't want to spend much time
> unpacking it, it seems pretty straightforward to get to that
> conclusion.

It is my understanding that we chose to work at bit level because not 
all our wires have the same data layout, because the costs/benefits are 
favourably balanced, and because it appears to be what most people want 
to see. I must admit though that that is not my area of predilection.

> I think some deeper problems of binary infosets may be that:
> - Different binary formats address different requirements,
>   so one binary infoset may not be enough.

Yes, that's why there's interest in adaptive and schema-based encodings. 
  Of course, they don't cover the full ground but they do cover much 
more than approaches that limits themselves to a single imutable schema.

The idea behind schema-based encodings is that they more or less provide 
different binary infosets depending on the schema(ta) of the document 
being encoded. That's one place where I'm having some trouble with HTTP 
because it doesn't allow for parameters (in the style of mime params) to 
content coding tokens. If I send an SVG document encoded as a binary 
infoset I would like to put it as Content-Type: image/svg+xml and 
Content-Encoding: (x-)bix;schema:SVGt1.1 (or some similar syntax using 
the namespace, possibly pointing to the schema document, or to the 
decoder bytecode). That information can be encoded into the document, 
but it'd be a lot cleaner if I could resort to content negociation, or 
get a 415. It's a pity to reinvent wheels that the web has already.

> - Compression is an interesting topic with a lot of engineering
>   opportunities and tradeoffs, and this has a tendency to lead
>   to over-engineering (in other words, you can impress your boss
>   or get a PhD if you invent a new compression method, but you'll
>   get much less recognition and no PhD if you just say that you
>   don't think compression is necessary (I did my PhD in image
>   compression :-))

Hehehe, very true :) Thankfully I'm attempting neither, and I do have a 
good number of use cases on my desktop where there is a choice between 
binary infosets and hand-carved binary structures. The former are much 
easier to extend, update, and create (as all happens at a higher level) 
for performance that is usually almost as good. Also note that in a 
number of cases compression isn't what interests people as much as 
decoding speed.

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

Received on Wednesday, 16 October 2002 10:12:09 UTC