Re: [EXI LC comments] Date-Time alignment on binary

Dear,

I consider keeping my request as valid. For the time beeing, I will wait for
your answer on the other issues I've raised to tell if it looks consistent
to me

Regards,

Mohamed

On Wed, Oct 15, 2008 at 11:05 PM, Taki Kamiya <tkamiya@us.fujitsu.com>wrote:

> Hi Mohamed,
>
> Thank you for getting back to us on this issue.
>
> We found your points valid, however, at the same time we believe that
> the suggested change would achieve only negligible performance
> gain in the context of the whole EXI processing.
>
> Since we expect that it would bring no noticeable performance
> difference from the end user's point of view thus no compelling
> benefit everyone can harness from, at this point we found ourselves
> reluctant to make the requested change for now, given its impact on
> generated test data and implementations. Having said that,
> we would like to leave the issue still open, and may consider including
> the change in the future if we find a good chance to do it.
>
> We appreciate your attention and inputs to our work.
>
> Regards,
>
> -taki
>
>
> -----Original Message-----
> From: public-exi-comments-request@w3.org [mailto:
> public-exi-comments-request@w3.org] On Behalf Of Innovimax SARL
> Sent: Wednesday, October 08, 2008 1:35 AM
> To: Taki Kamiya
> Cc: public-exi-comments@w3.org
> Subject: Re: [EXI LC comments] Date-Time alignment on binary
>
>
> Hi Taki,
>
> I'm sorry, but I'm not convinced by your argument
>
> EXI is a transport format and not a computing format
>
> If user have to make computation on date they have ANYWAY to decode
> the EXI format
>
> The proposal I made, is to :
> 1) improve the encoding time
> 2) improve the decoding time
> 3) be keen with use that have to access to SEPARATE DATA
>
> The answer you give is only focused on providing simple use case for
> user that need to compute data, which seems very poor use case with
> respect to the rest
>
> Regards,
>
> Mohamed ZERGAOUI
>
> On Tue, Oct 7, 2008 at 11:04 PM, Taki Kamiya <tkamiya@us.fujitsu.com>
> wrote:
> >
> > Hi Mohamed,
> >
> > Thank you for reviewing the specification and providing us a valuable
> > feedback.
> >
> > The primary reason why we combine hours and minutes in one component
> > in 11 bits as "hours * 60 + minutes", and also hours, minutes and seconds
> > as one component in 17 bits as "((hour * 60) + minutes) * 60 + seconds"
> > is that applications tend to manage these values as one, continuous
> value.
> >
> > For example, hypothetical timezone (hour, minute) = (5, 15) can be
> > combined as 5 * 60 + 15 = 315 minutes. This combined value is directly
> > useful for operations such as normalizing local time into UTC time.
> > Similarly, given two combined time values (hour, minute, seconds) =
> > (9, 30, 45) and (6, 20, 25), you can calculate the difference just by
> > subtracting one from the other as 34245 - 22825 = 11420 seconds.
> > To facilitate the encoding and decoding of these combined values,
> > we chose the 60 as the multipler instead of 64. We believe that the
> > added cost of computation is negligible in broader context and may
> > be outweighted by the merit described above in common use cases
> > employs direct language bindings.
> >
> > Thanks!
> >
> > -taki
> >
> >
> >
>
>
>
> --
> Innovimax SARL
> Consulting, Training & XML Development
> 9, impasse des Orteaux
> 75020 Paris
> Tel : +33 9 52 475787
> Fax : +33 1 4356 1746
> http://www.innovimax.fr
> RCS Paris 488.018.631
> SARL au capital de 10.000 €
>
>


-- 
Innovimax SARL
Consulting, Training & XML Development
9, impasse des Orteaux
75020 Paris
Tel : +33 9 52 475787
Fax : +33 1 4356 1746
http://www.innovimax.fr
RCS Paris 488.018.631
SARL au capital de 10.000 €