W3C home > Mailing lists > Public > public-device-apis@w3.org > September 2009

Re: ISSUE-7: Gathering requirements [Calendar API]

From: Robin Berjon <robin@robineko.com>
Date: Wed, 23 Sep 2009 13:37:46 +0200
Cc: <public-device-apis@w3.org>
Message-Id: <4C331BB8-0B47-42FA-9B22-08984CC8AD51@robineko.com>
To: <richard.tibbett@orange-ftgroup.com> <richard.tibbett@orange-ftgroup.com>
On Sep 16, 2009, at 18:32 , <richard.tibbett@orange-ftgroup.com> <richard.tibbett@orange-ftgroup.com 
 > wrote:
> Key Functionality:
> * Create a new calendar event
> * Update an existing calendar event
> * Remove an existing calendar event
> * Find existing calendar events

This does not include support for multiple calendars, is that  

> Notes:
> * An iCalendar [1] format MUST be used to represent an 'event' object
> throughout the Calendar API.

This bit is not clear: iCalendar is a format, whereas we'd have to  
deal with an API. Are you saying that the data model behind the format  
(which is quite extensive) should be supported by objects  
encapsulating events? Because that brings in a fair amount of  
information  not that I disagree with mapping to iCalendar, but we  
should discuss how extensive we are. At the very least summarising  
what iCalendar offers (e.g. repeats, all-day events, etc.) would be  

One further thing that isn't included here is the ability to export to  
an iCalendar file. If the model is iCalendar anyway it should be  
simple, but as a requirement it's rather useful because it can then be  
attached to an email.

> Does anyone expect any more than this in the first instance of API
> requirements? Does anyone see the need to break down the key
> functionality to medium and low level requirements at the beginning or
> during the API creation phase?

No, but detailing this a little bit when referencing an external  
source is helpful.

> Perhaps others have different views on the best process to use. For
> example, an alternative proposal could be to begin with use cases and
> work out the required functionality from there or to look at existing
> implementations and identify the shared core functionality as the  
> basis
> for any given API (FYI, the Calendar API requirements included above  
> are
> a loose paraphrasing of BONDI Calendar API requirements).

Right. As discussed before we'll only go to the more complex, heavy  
requirements process if the lightweight one doesn't work.

Robin Berjon
   robineko  setting new standards
Received on Wednesday, 23 September 2009 11:38:21 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:38 UTC