Comparing recurrence in iCalendar and current Calendar API

Hi,

Comparing the recurrence model in the latest iCalendar RFC [1] and the
current Calendar API editors draft [2] (as per my ACTION-227), I’ve
found the following discrepancies:
* the duration of an event in iCalendar can be determined either by and
end time, or by a duration; while for single instances events these two
can be calculated as equivalents, for recurring events, this doesn't
work any more; I think we probably need to encapsulate (start, end,
duration) in an interface (CalendarPeriod?) of its own that can be
re-used here and in other places

* iCalendar allows recurrence at specified dates (through the RDATE
property) rather than just through a well-known rule; we could handle
this in the calendar API with an additional recurrenceDates attribute
that would take an array of "CalendarPeriod" objects

* the RepeatRule needs to have a limit to the number of recurrence (the
COUNT parameter of the RECUR format in iCalendar)

* the current Calendar API doesn't cover specifying repetition based on
seconds (BYSECOND), minutes (BYMINUTE), hours (BYHOUR)

* the current Calendar API doesn't cover specifying the 2nd Monday of
each month (which iCalendar deals with by combining a numeric factor in
the BYDAY list within a MONTHLY frequence); likewise for the Xth weekday
of each year

* there are some disallowed combination in iCalendar that should be
create an exception in our API; e.g. "The BYYEARDAY rule part MUST NOT
be specified when the FREQ rule part is set to DAILY, WEEKLY, or
MONTHLY."

* we don't have weeksInYear (which would match the BYWEEKNO rule in
iCalendar)

* we don't have a way to specificy when the week starts, which matters
for the weekly frequence when combined with a specific day in the week,
or when specifying the weeksInYear; this is handled in iCalendar with
WKST

* we don't have the equivalent of BYSETPOS to select a subset of
occurrences in a set of recurrence rules (knowing that interval is meant
to be applied before the other repetitions are calculated)

These are the main points I could identify from a relatively cursory
glance; I think once we have them fixed, we probably ought to encode the
examples in 3.8.5.3 of the iCalendar spec as objects in our APIs to see
if everything fits well; these can then be re-used as test cases for the
spec.

(the lack of proper timezone information is also a source of
inconsistency with iCalendar, but since we already have a plan to fix
this, I haven't listed this as a discrepancy on its own)

Dom

1. http://tools.ietf.org/html/rfc5545#section-3.8.5
2. http://dev.w3.org/2009/dap/calendar/#calendarrepeatrule-interface

Received on Wednesday, 21 July 2010 09:19:22 UTC