W3C home > Mailing lists > Public > public-exi-comments@w3.org > October 2008

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

From: Taki Kamiya <tkamiya@us.fujitsu.com>
Date: Wed, 15 Oct 2008 15:05:00 -0700
To: "'Innovimax SARL'" <innovimax@gmail.com>
Cc: <public-exi-comments@w3.org>
Message-ID: <1C5F8FCAA2E44171B098FA0E001E186C@catarojp>

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.



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



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
RCS Paris 488.018.631
SARL au capital de 10.000 €
Received on Wednesday, 15 October 2008 22:05:48 UTC

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