Re: Feedback of EXI specification 1

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!


-- 
TOORU Ishizaki <ishizaki.tooru@canon.co.jp>

Received on Wednesday, 28 January 2009 02:50:58 UTC