W3C home > Mailing lists > Public > public-exi-comments@w3.org > February 2009

Re: Feedback of EXI specification 1

From: Jaakko Kangasharju <jkangash@cc.hut.fi>
Date: Mon, 16 Feb 2009 15:48:09 +0200
To: ISHIZAKI Tooru <ishizaki.tooru@canon.co.jp>
Cc: public-exi-comments@w3.org, youenn.fablet@crf.canon.fr, fujisawa.jun@canon.co.jp
Message-ID: <86wsbqfq7a.fsf_-_@cc.hut.fi>


Yes, that is correct. As I calculate it, according to the current
specification when the non-default alignment options are not used, the
presence or absence of the compression option is indicated by a single
bit. Similarly, your request would require two bits, and because of
padding, that extra bit may turn into an extra byte.

ISHIZAKI Tooru <ishizaki.tooru@canon.co.jp> writes:

> Hello Jakko-san, and WG members,
> Thank you for the detailed explanation.
> I would like to confirm your reply. Is it ok?
> In current specification, there are alignment option and 
> compression option. Our request is making new option which 
> indicates both alignment and compression.
> Our request decreases the number of the header option, but it
> has four possible values
> (bit-packed, byte-alignment, pre-comression, compression).
> So our request needs more bit-length for representing than 
> current specification. Is it right?
> Best Regards,
> Tooru Ishizaki.
>> ISHIZAKI Tooru <ishizaki.tooru@canon.co.jp> writes:
>> > Dear EXI members,
>> >
>> > In chapter 5.4(EXI Options), alignment option and EXI compression
>> > option can be unified.
>> > Then option values are
>> >  - bit-packed, byte-alignment, pre-compression, compression
>> >
>> > If doing so, the implementation will be more simple.
>> Hello Tooru,
>> Thank you for your comment. You are correct in that the four options
>> you present are the only possible ones from the alignment-compression
>> pair.
>> The reason why alignment and compression are separated as options is
>> to achieve better compactness for the EXI Options header. It is
>> expected that EXI compression is used often, so it is placed in the
>> "common" part of the Options header, whereas the non-default alignment
>> options are expected to be used only in very special circumstances and
>> are therefore placed in the "uncommon" part. This reduces the size of
>> the Options header in the usual case when the default alignment is
>> used.
>> But none of this prescribes any particular implementation strategy. An
>> implementation is free to adopt the approach that you suggest,
>> including in its API, as long as it produces and is able to consume
>> correct Options headers.
>> Hope this helps,
>> -- 
>> Jaakko Kangasharju, Helsinki University of Technology
>> Remember to sacrifice regularly to Shub-Internet
>> Otherwise, anything may ha?$^&%?@$Ia! FThAGN!Ia!CTHulHu!

Jaakko Kangasharju, Helsinki University of Technology
Will you be my friend, please?
Received on Monday, 16 February 2009 13:51:16 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:45:28 UTC