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

Re: Feedback of EXI specification 1

From: ISHIZAKI Tooru <ishizaki.tooru@canon.co.jp>
Date: Fri, 27 Feb 2009 11:17:21 +0900
To: Jaakko Kangasharju <jkangash@cc.hut.fi>
Cc: public-exi-comments@w3.org, youenn.fablet@crf.canon.fr, fujisawa.jun@canon.co.jp
Message-Id: <20090227104656.F194.ISHIZAKI.TOORU@canon.co.jp>
Hello Jakko-san,

Thank you very much for the explanation.
I understood what you said.

In our usecase, program size is more sensitive than data size.
Because data can be processed on streaming, but program unavoidably
impacts to ROM size.

So I hope WG member will consider not only data size but also 
programming size. 

Best Regards,
Tooru Ishizaki.

> 
> 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?

-- 
TOORU Ishizaki <ishizaki.tooru@canon.co.jp>
Received on Friday, 27 February 2009 02:12:36 UTC

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