- From: Jaakko Kangasharju <jkangash@cc.hut.fi>
- Date: Mon, 11 May 2009 13:02:55 +0300
- To: ISHIZAKI Tooru <ishizaki.tooru@canon.co.jp>
- Cc: public-exi-comments@w3.org, youenn.fablet@crf.canon.fr, fujisawa.jun@canon.co.jp
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
Received on Monday, 11 May 2009 10:04:58 UTC