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

Hi Rich,

--On September 8, 2010 1:06:49 AM +0200 Rich Tibbett <richt@opera.com> 
wrote:

> But there's also a pragmatic sausage-factory aspect to take into
> consideration. It seems that properly supporting recurrence in
> non-Gregorian calendars would require non-trivial changes to iCalendar.
> We're happy to help, but we're the wrong group to do that. I think this
> is pointing at an update to iCalendar, which we would mirror in a future
> revision.
>
>
> I reflect this opinion. It does defer the onus to IETF but the W3C effort
> here is not to invent new calendaring formats at the expense of
> interoperability with existing formats (iCalendar). We hope this
> discussion and others will be helpful to the groups defining these
> formats and we will provide any and all input that we can to that process.

Interest could be garned in the IETF provided there is a strong 
recommendation from W3C to do this work - i.e. it is clear that it will be 
used. That said, I am pretty clear that the "regular" IETF calendaring 
folks who would likely be involved in this would want input from 
non-Gregorian calendar users to ensure we get any changes right.

> 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).

>   • an X-USER-CALENDAR extension (which we'd define) be included to
> specify which calendaring system to use when displaying the event?

That would be a property in an event that indicates that date/time values 
should be displayed in a specific calendar scale rather than just Gregorian.

> This could be good, though perhaps a client will just choose to display
> an event based on the current user's locale rather than on the original
> format used to specify the event.

I agree that in most cases users will only want to see events in the 
calendar scale they are familiar with, so in all likelihood clients will 
just ignore any "hint" property and instead would have an option to change 
the entire calendar view to a particular calendar scale.

> The user has a local calendaring mode, the storage is in Gregorian and so
> we can do conversion (or not) based on that information. At the point of
> displaying the calendaring data the non-Gregorian system used to generate
> the event has already been wiped out (in exchange for X number of
> recurrence representations). The user's locale is important here as
> compared to the originator's calendaring locale for displaying any
> recurrence rules included. So if the user is on a Gregorian system then
> display the event in a Gregorian format. If the user is on a Lunisolar
> system then pass the date information through a convertor and then
> display the event in the Lunisolar format.

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.

I should also point out that RDATE has a poor interoperability record. Many 
clients are known to ignore RDATEs (including Outlook). So at the very 
least this approach would need suitable buy-in from the major client 
developers to provide proper support. But then again we would require them 
to make changes for new calendar scales anyway...

-- 
Cyrus Daboo

Received on Wednesday, 8 September 2010 15:07:15 UTC