| I wonder if this proposal is of interest also from the Chandler design perspective... I've run this by Jeffrey already, happy to hear what others think. Lisa Begin forwarded message:
|
A Minimal Profile of RRULE for inter-personal scheduling These RRULE simplifications are intended for VEVENTS (not necessarily timezones or tasks) in the context of: - Any calendar that is exported, with the intent to import it into a personal calendar application - Any interpersonal scheduling request - Any CalDAV calendar WHY? It's not because it's impossible to write iCalendar libraries. Instead I have a couple other concerns:
a) This is really the core concern: display of recurrence rules. We could just
use recurrence dates, except that we'd lose the functionality of one person
modifying the recurrence pattern for a recurring event, and the functionality
of quickly grasping the recurrence pattern when I'm invited to something. If
I'm accepting an invitation or modifying an event, it's crucial to understand
quickly that "This event is scheduled every other week except for Christmas"
rather than have to grovel through actual recurrence dates. Thus, I conclude
that the ability to display a recurrence rule is crucial to the usefulness of
recurrence rules in VEVENTS involving real people. RRule uses which can't be
displayed by the client are harmful to usability and interoperability.
b) Many combinations are meaningless, ambiguous or nearly so, even if we limit
ourselves to clauses that are actually in common use. Some examples to try to
remove:
FREQ=YEARLY;BYDAY=FR -- is this every friday? The first friday each year?
FREQ=DAILY;BYMONTH=3
FREQ=WEEKLY;BYDAY=FR;BYMONTHDAY=26
c) Some kinds of recurrences can be represented in more than one way. It's an
improvement in interoperability to *reduce* the number of options for
representing a given recurrence.
FREQ=DAILY;BYDAY=MO,WE,FR
FREQ=WEEKLY;BYDAY=MO,WE,FR
d) We should have a model where we're clearly limiting or expanding recurrences
with a BY* clause but not both. The model is too complex when the evaluation
is context-specific so we should fix this.
FREQ=DAILY;BYDAY=MO,WE,FR -- this limits/filters occurrences, to less than
the default DAILY
FREQ=WEEKLY;BYDAY=MO,WE,FR -- this multiplies occurrences beyond the
default WEEKLY
How do I know which recurrence features can be displayed? I tested Apple's
iCal, Chandler, Yahoo and Google Calendar GUIs (and would welcome additional
cases). iCal is the most flexible of these across all possible rules, with the
possible exception that Google has an "Every weekday" rule option that Apple
could probably duplicate by letting the user pick checkboxes for MoTuWeThFr.
If we were really to go with lowest common denominator we could be even more
brutal but I don't think we want to.
FEATURES TO FORBID in VEVENT RRULES for display
#1. Only one recurrence rule per RRULE
#2. No EXRULE
#3. No FREQ = SECONDLY, MINUTELY and HOURLY.
#4. No BYSECOND, BYMINUTE, BYHOUR, BYYEARDAY, BYWEEKNO and BYSETPOS.
#5. No WKST, because the rules that have a dependency on when the week starts
are gone now.
COMBINATIONS TO REMOVE
#6. Fewer combinations of BY* clauses together, fewer combinations of a given
frequency and inappropriate BY* clauses:
* MUST NOT combine BYDAY and BYMONTHDAY.
* MUST NOT combine DAILY frequency and ( BYDAY or BYMONTHDAY or BYMONTH)
* MUST NOT combine WEEKLY frequency and BYMONTH
* MUST NOT combine MONTHLY frequency and BYMONTH
* MUST NOT combine YEARLY frequency and BYDAY unless there's also a BYMONTH
(because "every year on the 52nd Monday" is too useless)
#7. MUST NOT have more than one of any kind of clause (INTERVAL, UNTIL, COUNT,
BYDAY, BYMONTHDAY, BYMONTH)
#8. When the old "ordwk" was used (to specify the 3rd Friday or 1st monday),
it didn't make sense with WEEKLY frequency. When the old weekday stuff was
used (e.g. every Tuesday and Thursday) it didn't make sense with monthly
freqency or yearly. Thus, split these two concepts into two and limit usage.
OTHER VARIATION TO REMOVE
#9. MUST use the canonical ordering of clauses. Frequency obviously comes
first, then INTERVAL (required?) then UNTIL or COUNT (optional?) then BYDAY,
BMONTHDAY and BYMONTH (with the combination restrictions above)
#10. MUST include the INTERVAL
#11. When specifying the "Nth weekday of a Month", only options are:
1, 2, 3, 4, 5 and -1
(Thus remove option for "-4MO" or the fourth-to-last Monday of the month)
Similarly, the only "ordmoday" that is negative is -1.
--------
RESULT: An example of rewriting the ABNF completely with what you CAN have --
only the combinations that make sense.
recur = "FREQ=DAILY" interval [ limit ]
=/ "FREQ=WEEKLY" interval [ limit ] [ chooseweekday ]
=/ "FREQ=MONTHLY" interval [ limit ] [ choosemonthday ]
=/ "FREQ=YEARLY" interval [ limit ] [ choosemonth [ choosemonthday ] ]
interval = ";" "INTERVAL" "=" 1*DIGIT
limit = ";" ( "UNTIL" "=" enddate ) / ( "COUNT" "=" 1*DIGIT )
chooseweekday = ";" ( "BYDAY" = weekdaylist )
choosemonthday = ";" ( "BYDAY" = nthweekdaylist )
/ ( "BYMONTHDAY" = monthdaylist)
choosemonth = ";" "BYMONTH" = bymolist
enddate = date
enddate =/ date-time ;An UTC value
weekdaylist = weekday [ *("," weekday) ]
nthweekdaylist = nthweekday [ *("," nthweekday) ]
nthweekday = ("1" / "2" / "3" / "4" / "5" / "-1" ) weekday
weekday = "SU" / "MO" / "TU" / "WE" / "TH" / "FR" / "SA"
;Corresponding to SUNDAY, MONDAY, TUESDAY, WEDNESDAY, THURSDAY,
;FRIDAY, SATURDAY and SUNDAY days of the week.
monthdaylist = monthdaynum / ( monthdaynum *("," monthdaynum) )
monthdaynum = ("+" ordmoday) / ( "-1" )
ordmoday = 1DIGIT / 2DIGIT ;1 to 31
bymolist = monthnum / ( monthnum *("," monthnum) )
monthnum = 1DIGIT / 2DIGIT ;1 to 12
--------
NOTES ON REDUCED FUNCTIONALITY
What is this simplification *not* good for? What are its effects?
REMOVING HOURLY: This makes simplified recurrence rules less useful for some
kinds of repetitive tasks, particularly automated tasks. Let's consider this a
separate kind of application, as it doesn't affect VEVENTs in interpersonal
scheduling.
REMOVING BYHOUR:
With the removal of BYHOUR, some timezone rules don't work. We need to make
RRULE BYHOUR understood for timezones, but NOT for interpersonal scheduling.
There are examples of BYHOUR at
<http://tipi.sourceforge.net/doc/recur/indexs01.html> but I've never seen this
in actual interpersonal scheduling.
An example at <http://www.orafaq.com/node/862> uses BYHOUR but could express
the same rule with the reduced syntax.
REMOVING BYYEARDAY:
An example: RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU;BYYEARDAY=72
This is pretty stupid. Only leap years affect whether the 72nd day of the year
is 31+28+13 = March 13 or 31+29+12 = March 12. It's just not useful enough to
schedule a meeting on "March 13, except March 12 if it's a leap year" and that
kind of use case can be worked around. (One special case might be to state
that a RRULE that occured yearly on Feb 29 might automatically recur on Feb 28
if not a leap year) So without BYYEARDAY we'd see rules like
"RRULE:FREQ=YEARLY; INTERVAL=1" and the date would be March 12 every year.
REMOVING BYWEEKNO:
An example: RRULE:FREQ=YEARLY;BYWEEKNO=1;BYDAY=5SU
This was crafted to show how combining BYWEEKNO with other BY* clauses
generates non-sensical events.
Apple's iCal doesn't create BYWEEKNO. It only uses BYMONTH with a possible
modifier of BYDAY. So instead of a rule of
"RRULE:FREQ=YEARLY;BYWEEKNO=7;BYDAY=FR", an Apple iCal user would have to
generate "RRULE:FREQ=YEARLY;BYMONTH=2;BYDAY=3FR"
REMOVING BYSETPOS:
An example supposed to be "Last weekday of March":
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=MO,TU,WE,TH,FR;BYMONTH=3;BYSETPOS=-1;WKST=SU
iCal just can't recreate this. The closest iCal gets is "Every year on the
last friday of March" which is
RRULE:FREQ=YEARLY;INTERVAL=1;BYMONTH=3;BYDAY=-1FR. It's also true that iCal
can't display this.
Is there an alternative? Could we specify a special BYDAY code for "A weekday"
in order to make this work? E.g.
RRULE:FREQ=YEARLY;INTERVAL=1;BYMONTH=3;BYDAY=-1WK
For better backward compatibility, another alternative is to require all
clients to understand this one application of BYSETPOS, if at least some
minimum number clients are willing to do the display work.
REMOVING COMBINATION OF DAILY + BYMONTH:
What about "Every April, I need to have a series of meetings that is every work
day all month"? In the old rules this could be:
RRULE:FREQ=DAILY;BYMONTH=4;BYDAY=MO,TU,WE,TH,FR
With this simplification you just can't do that. The best a client could do is
to create a "FREQ=DAILY;UNTIL=20060430;BYDAY=MO,TU,WE,TH,FR" from the beginning
to the end of April, each year.
REMOVING ABILITY TO COMBINE RRULES
My quilting group actually meets every 4th saturday and every 4th tuesday
evening, with the saturday offset from the tuesday meeting by being 2.5 weeks
after the Tuesday meeting. Our Yahoo group administrator actually put this on
the Yahoo calendar by... creating *2* recurring events. If Yahoo could express
this in RRULE it would probably be two VEVENTS with something like
DTSTART:20060523T193000
RRULE:FREQ=WEEKLY;INTERVAL=4
and
DTSTART:20060610T193000
RRULE:FREQ=WEEKLY;INTERVAL=4
|
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Design" mailing list http://lists.osafoundation.org/mailman/listinfo/design
