Re: [calendar] Editor's Draft of Calendar API

There are also floating time assignments:  I.e., an alarm that goes off at 6am local time, whatever time zone the device (and its owner) might be in.

Upleveling, it's not immediately clear where the specification follows the vCalendar data model (from RFC 5545) and where it doesn't (and why).  For example, it appears like this specification introduces a recurrence model that's separate from vCalendar's.  That sounds like a recipe for significant trouble later on.

Regards,
--
Thomas Roessler, W3C  <tlr@w3.org>







On 27 Jan 2010, at 11:32, Dominique Hazael-Massieux wrote:

> Le vendredi 22 janvier 2010 à 15:10 +0100,
> richard.tibbett@orange-ftgroup.com a écrit :
>> The first editor's draft of the Calendar API is now available:
>> http://dev.w3.org/2009/dap/calendar/
> 
> I think this is a great start, thanks!
> 
> A few early comments:
> • converting all date and times into UTC timestamps prevents having
> recurring events in a given timezone; typically, our DAP WG calls are
> recurring in the US Eastern Timezone, but I don't know that you could
> create such an event with the current API (nor how they would get
> converted to the relevant object by an implementation)
> 
> • recurrent events need to have exceptions; the Nokia API had 
> "attribute sequence<DOMTimeStamp> exceptionDates;"
> http://lists.w3.org/Archives/Public/public-device-apis/2009Apr/att-0001/calendar.html#calendar_entry_interface
> 
> • recurrent events needs an interval (e.g. for events that occur every
> two weeks): the Nokia API has it
> 
> • the Nokia API had also instanceStartTime for recurring events; I'm not
> entirely sure if it's needed in addition to the base start/end times of
> the base event
> 
> • I think CalendarOptions should probably be renamed to
> CalendarSearchFilter (as a note suggested similarly in the contacts API)
> 
> Dom
> 
> 
> 
> 

Received on Wednesday, 27 January 2010 11:10:14 UTC