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

Re: doodle (Re: Scheduling calendaring coordination call.)

From: Rich Tibbett <richt@opera.com>
Date: Fri, 10 Sep 2010 15:00:59 +0200
Message-ID: <4C8A2C0B.4090907@opera.com>
To: Cyrus Daboo <cyrus@daboo.name>
CC: Robin Berjon <robin@robineko.com>, Rich Tibbett <rich.tibbett@gmail.com>, Thomas Roessler <tlr@w3.org>, W3C Device APIs and Policy WG <public-device-apis@w3.org>
Cyrus Daboo wrote:
> Hi Rich,
> --On September 8, 2010 1:06:49 AM +0200 Rich Tibbett <richt@opera.com>
> wrote:
>> Robin Berjon wrote:
>>> I'd like to find a solution that is as I18N-friendly as possible but can
>>> be made to work atop iCalendar as deployed today. I'm not at all fluent
>>> with calendar modelling, but could we recommend that:
>>> • in version 1, for non-Gregorian calendars, a long list of RDATE be
>>> generated; and
>> This could certainly work for non-Gregorian usage.
>> A long list of RDATE is certainly a workable proposal for lunisolar
>> recurrence in the first instance, essentially distilling recurring events
>> to a finite set of 'static' dates that can be modelled as Gregorian dates
>> for storage purposes.
>> It builds atop of what we currently have in iCalendar but obviously has
>> its limitation at X number of recurrences. So what is X? Is it an
>> arbitrary implement-dependent or independent value?
>> A first version like this allows us to build atop of an iCalendar
>> compliant design in subsequent versions in sync with iCalendar
>> development around this topic.
> So one option for dealing with unbounded instances is to use the RDATE
> list. What would make that better is a way to "link" multiple iCalendar
> components together when those components are each ranges for the same
> overall recurring events. e.g. One event would cover recurrences in
> 2010, another in 2011, etc. If we have links between them, then calendar
> clients could manipulate them as a whole (e.g. when the user moves the
> 2010 event to another calendar the client could offer to move all the
> following years ones too). Overall that would lead to a better user
> experience.
> Now it turns out that iCalendar has a RELATED-TO property that does
> indeed allow one component (event) to be related to another. However, I
> think we need to define some new values for that property to indicate an
> "on-going recurrence" relation.
> Another considerations: often times things like holiday calendars are
> managed through internet calendar subscriptions - i.e. an iCalendar
> object containing multiple events that calendar clients "subscribe" to
> via an HTTP download (<http://icalshare.com/> is a good example of
> that). If we have an "on-going recurrence" model it would be good to add
> some additional properties to help clients find out about new additions.
> e.g., a calendar subscription is created for "US Holidays" that contains
> holidays for 2010. A property in the event could tell the client that an
> update for 2011 will follow and the client should check back
> automatically one month before 2011. By doing that, clients can avoid
> unnecessarily polling the server for updates.
> A good place to discuss possibilities like this is the Calendaring and
> Scheduling Consortium
> which has typically been the place where new iCalendar work is done
> (with specifications being submitted to the IETF).

So the object itself, regardless of the event it may contain, can itself 
expire at a predefined date. If we include X number of RDATE based 
recurrences within that object, then it could expire at e.g., X-1.

At X-1, or at any time before X-1, the user agent can obtain an 
additional follow-on object (if included) that will include Y number of 
additional recurrences represented as RDATEs for the next period. At Y-1 
(or any time before Y-1) the next follow-on object could be obtained. 
And so on.

Using this we could convert internationalized dates to the gregorian 
calendaring system without imposing limitations on the duration of 
recurrence rules that have been generated in different calendaring systems.

 > As I noted before, the main disadvantage of using an RDATE list as
 > opposed to an RRULE is that the "pattern" of the recurrence is lost.
 > i.e. a list of dates does not obviously convey the meaning of "every
 > Monday at 10 am". That makes it hard to adjust the event in the case
 > where changes are needed.

Right. Any further proposals from members of the group around RRULE 
would be most appreciated. At this stage we have a proposal to support 
non-Gregorian calendars only based on RDATE which should probably be 
considered as an interim but workable solution.

- Rich
Received on Friday, 10 September 2010 13:01:39 UTC

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