Re: Feedback of EXI specification 1

Hello,

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