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

Re: Feedback of EXI specification 1

From: ISHIZAKI Tooru <ishizaki.tooru@canon.co.jp>
Date: Fri, 22 May 2009 14:44:05 +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: <20090522141953.7744.ISHIZAKI.TOORU@canon.co.jp>
Dear Jakko-san,
Thank you very much.

I'm happy to hear EXI WG teams consider also EXI program size.
I hope such consideration brings good effects to the reference
implementation.

Best Regards,
Tooru Ishizaki.

> 
> Hello,
> 
> Indeed, one of the requirements on the EXI format is that it must not
> prevent small-footprint implementations, and the group has people with
> experience in environments where program size is constrained, so program
> size considerations have also been present in the format design
> throughout the process.
> 
> ISHIZAKI Tooru <ishizaki.tooru@canon.co.jp> writes:
> 
> > 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?
> 
> -- 
> Jaakko Kangasharju, Helsinki University of Technology
> What good is Open Source without Freedom?
> http://www.gnu.org/philosophy/why-free.html
> http://www.gnu.org/philosophy/free-software-for-freedom.html


-- 
TOORU Ishizaki <ishizaki.tooru@canon.co.jp>
Received on Friday, 22 May 2009 05:44:58 UTC

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