- From: Dominique Hazael-Massieux <dom@w3.org>
- Date: Tue, 01 Feb 2011 17:48:22 +0100
- To: Rich Tibbett <rich.tibbett@gmail.com>
- Cc: Frederick.Hirsch@nokia.com, public-device-apis@w3.org
Hi Rich, Le mercredi 12 janvier 2011 à 11:06 +0100, Rich Tibbett a écrit : > I spent a couple of days updating the Calendar API according to > ACTION-320 [1]. I took the liberty to bring a few updates to the API to align it with recent changes to the Contacts API. Please find below further comments on the draft: The current find() function isn't quite like contacts.find() — you can't provide it with a list of fields/values to search for. Is that intended? I think what's currently in CalendarEventFilter should actually be moved as search fields in the first parameter of the method. There should also be capabilities to search for events based at least on their description, possibly more. I've noticed that times and dates are defined as DOMString valid in the HTML5 sense — this doesn't cater for the timezone-dependent needs that have already been discussed at length http://www.w3.org/2009/dap/track/issues/81 Is this as a stop gap solution while you're working on defining TZDate, or are you actually championing this particular solution? In any case, the draft should probably include a note about that issue. Also, I had identified a number of missing pieces to make the recurrence model of the API matches what's available in iCalendar: http://lists.w3.org/Archives/Public/public-device-apis/2010Jul/0115.html It would be good at least to note that current limitation (or even better to take the required steps to fix it). The extensibility mechanism used by the API (prefixing new properties with "X") isn't quite what others have been doing, where new properties/methods starts with -vendor- — should we align with this? (and do that with Contacts as well as a result) HTH, Dom
Received on Tuesday, 1 February 2011 16:48:39 UTC