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

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

From: <anssi.kostiainen@nokia.com>
Date: Tue, 29 Sep 2009 17:57:24 +0200
To: <marcosc@opera.com>, <dom@w3.org>
CC: <richard.tibbett@orange-ftgroup.com>, <robin@robineko.com>, <public-device-apis@w3.org>
Message-ID: <C6E80914.7089%anssi.kostiainen@nokia.com>

On 29.9.2009 12.32, "ext Marcos Caceres" <marcosc@opera.com> wrote:

>> I think the idea of using iCalendar as the basis for that API is that
>> most devices calendars support iCalendar in one way or another, and
>> thus, an API modeled on top of that format is likely to be usefully
>> implementable on a large number of devices.
> Ok, if this is the defacto, then great (again, I know almost nothing of
> this space). However, I think it would be of value to present evidence
> to prove that "yes, in fact, iCalendar is the defacto standard" by
> presenting a landscape analysis. Note that the landscape analysis might
> just be a simple list ("devices/systems/apps that use iCalendar: x, y, z").

In my previous mail I provided a list of apps supporting iCalendar [1]. The
list is incomplete but should give an idea of the adoption.

Another (de facto) standard of interest is hCalendar [2] referenced by
Richard which is a 1:1 (X)HTML representation of iCalendar event data model.
hCalendar has been gaining traction on the Web over the recent years. For
example, if we were to provide a mapping to the iCalendar event data model a
developer could quite effortlessly create a widget/web page containing
hCalendar entries and use a JavaScript library such as js-hcalendar [3] to
build a calendar view (see the demo).

> Also, there must be issues with iCalendar (there are always issues and
> limitations with every specification). What are they? What has been the
> implementation experience? Is there things in iCalendar that we can
> avoid, or that are really important etc.

Some (not strictly iCalendar only) implementation experiences have been
documented in RFC 3283 [4]. Also RFC 5545 (aka RFC 2245bis, the latest
iCalendar standard) documents the changes done based on implementation
experience in its Appendix [5]. More details can be found from IETF
"Calendaring and Scheduling Standards Simplification" WG home page at [6].

IETF has also specified a calendar access protocol called CalDAV (RFC 4791
[7]) which uses iCalendar as a data exchange format. Although it is an
HTTP-based protocol I believe we can learn from it while specifying the
Calendar API.

(Sorry for rather long list of links.)



[2] <http://microformats.org/wiki/hcalendar>

[3] <http://code.google.com/p/js-hcalendar/>

[4] <http://tools.ietf.org/html/rfc3283>

[5] <http://tools.ietf.org/html/rfc5545#appendix-A>

[6] <http://www.ietf.org/dyn/wg/charter/calsify-charter.html>

[7] <http://tools.ietf.org/html/rfc4791>
Received on Tuesday, 29 September 2009 15:58:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:32:11 UTC