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

Hi,

In previous discussions we discussed a requirement around producing a
1:1 mapping to RFC 5545: iCalendar [1] for our own Calendar API.

I'm currently going through that RFC 5545 spec and producing that 1:1
mapping in WebIDL with good ol' ABNF to WebIDL translation techniques. I
will provide the resulting WebIDL to the list once it is more complete.

My thoughts half way through this process are:

- that we are going to end up with a rather extensive set of WebIDL for
the Calendar API.
- significant custom attributes will account for a large number of
additional WebIDL interfaces.
- that there are a lot of nuances to the creation of iCalendar items
(events, todos, etc) which are likely to result in a lot of
misprogramming by developers and a lot of exceptions being thrown back
to the user if a calendar item is not correctly formatted.
- that a lot of the naming used in iCalendar isn't particularly
intuitive. Someone using our Calendar API for the first time won't find
properties like e.g. RRULE very self-explantatory. However, I'm
hesistant about confusing it further by mapping to a new set of
attributes in the WebIDL.


Having said all that, the resulting WebIDL will be very powerful and
flexible. iCalendar gives us the following capabilities:

- defining recurring events, 
- defining an expiry date for recurring events,
- adding or referencing attachments,
- defining the timezone settings of the organiser,
- defining the availability (free/busy time) of the organiser,
- adding, updating and removing todo and journal entries as well as
standard events
- event sequence control for rescheduling or proposing new times for
events
- event priority control (high/low)
- event transparency in calendar (whether to display busy status or not)
- attaching geolocation information to an event
- keeping track of event attendees
- adding custom properties to an event ('x-' attributes)
...

In addition, the current proposal enables output from our API will be
intentionally interoperable with existing and future iCalendar-based
implementations and iCalendar-based APIs available. 

We have previously discussed the extensive adoption of iCalendar in
existing device and server-based calendaring services (though no formal
study has been done, a lot of links and discussion have been previously
provided) so it follows logically that we should be prepared to
implement a compatible solution. It has also been previously stated that
producing a subset of the iCalendar spec has historically resulted (as
with the subset in SyncML) in increased fragmentation and problems in
cross-compatiblity when transfering calendaring information.

We haven't defined exactly what features are required at the Calendaring
Events level (and Todos and Journals) but the proposal 1:1 mapping, or
affectionately, the 'warts and all' approach, may just be the right one
considering the extensive implementation of iCalendar and the inevitable
sharing of Calendar information between devices and services based on
this existing standard.

So this is just a sanity check and a heads up that this may be an
extensive set of WebIDL that results from this work...fleixble calendars
turn out to be complicated beasts...and to see if anyone has any
alternative thoughts or input on how they see this API shaping up. 

I currently agree with RFC 5545 as an all or nothing for the Calendar
API. I'm hesistant about producing anything less than a 1:1 mapping but
it's a question of flexibility/interoperability vs. simplicity of the
resulting Calendar API.

Any thoughts?

Kind Regards,

Richard

[1] <http://tools.ietf.org/html/rfc5545>


> -----Original Message-----
> From: public-device-apis-request@w3.org 
> [mailto:public-device-apis-request@w3.org] On Behalf Of 
> Andrew McMillan
> Sent: 30 September 2009 23:36
> To: TIBBETT Richard RD-ILAB-LON
> Cc: public-device-apis@w3.org
> Subject: RE: ISSUE-7: Gathering requirements [Calendar API]
> 
> On Wed, 2009-09-30 at 17:27 +0200, richard.tibbett@orange-ftgroup.com
> wrote: 
> > Hi Andrew,
> > 
> > Getting back to you on this my belief is that a Calendar API will 
> > execute over locally held resources (a calendar on the 
> device) rather 
> > than against a remote server-based calendaring service. A 
> lot of your 
> > proposed requirements address interaction with a remote service.
> 
> OK, my apologies - someone pointed me at the discussion for 
> the issue and I signed up for the list, but that wasn't 
> clear.  I will adjust my thinking immediately :-)
> 
> 
> > Your proposal for server-based interaction may be relevant 
> and indeed 
> > useful but I would be hesitant about including this as high level 
> > requirements right now based on the reasons stated above and partly 
> > because of the lack of their inclusion in the two Calendar 
> API inputs 
> > to date ([1] and [2])...and perhaps the reasoning behind that.
> 
> Absolutely.
> 
> 
> > > * Tell me (X,Y,Z) properties of the calendar please
> > > 
> > > The sorts of data associated with calendars might include default 
> > > timezone, preferred display colour (this is useful where the user 
> > > access the calendar from multiple devices and wants a consistent 
> > > colour scheme across all devices).
> 
> I think it's worth having some properties for calendars.  In 
> particular the colour to use for display of events, a 
> meaningful name to display to associate with the calendar and 
> the default timezone for the calendar are common ones I have 
> seen implemented.
> 
> 
> With regard to the general use of RFC5545 as a base 
> definition for the structure of stored calendar resources, I 
> do think that 'warts and all'
> is definitely the best approach, and it would not be good to 
> limit interoperability by deciding on some subset as a standard here.
> 
> Regardless of whether this specification is for a local 
> calendar, the entries in the calendar will inevitably find 
> themselves in other calendars through whatever transfer 
> mechanisms are used by clients to forward meeting information 
> to external parties, or through synchronisation with remote 
> calendars.  Similarly event data sourced elsewhere will find 
> itself ensconced (hopefully happily) in these calendars, and 
> any adjustment of features that is to be implemented will add 
> substantial complexity at that interface, without gaining 
> much reduction elsewhere in the application.
> 
> A commonly desired request is to convert a task to an 
> appointment, and vice-versa, or (less commonly) to convert 
> either of those into a journal (as a record of meeting notes, 
> for example).  Given that the differences between VEVENT & 
> VTODO are trivial in comparison to the complexity of their 
> common elements, and that VJOURNAL is entirely a subset of 
> those, it seems to me there is very little to gain by 
> removing VTODO and VJOURNAL from this specification. Removal 
> might restrict clients from implementing some potentially 
> useful functionality.
> 
> The other supporting components of the specification like 
> VALARM and VTIMEZONE seem to me so essential in any 
> reasonable implementation of VEVENT that they don't even 
> merit discussion.
> 
> 
> Something that this API should probably also consider is some 
> way of collating the alarms due during a future period of 
> time.  A mobile device will often have a very low power mode 
> which might need to know when to wake up.  The ability to 
> query for 'alarms due before such and such time' (or perhaps 
> just 'when is the next alarm due') would be useful 
> information for a device about to enter low power sleep so it 
> can correctly schedule it's next wakeup.
> 
> 
> Regards,
> 					Andrew McMillan.
> 
> 
> --------------------------------------------------------------
> ----------
> http://andrew.mcmillan.net.nz/                     Porirua, 
> New Zealand
> Twitter: _karora                                  Phone: 
> +64(272)DEBIAN
>          Flexibility is overrated.  Constraints are liberating.
> --------------------------------------------------------------
> ----------
> 
> 
>

Received on Tuesday, 6 October 2009 14:24:46 UTC