- From: Andrew McMillan <andrew@morphoss.com>
- Date: Fri, 29 Jan 2010 01:39:58 +1300
- To: richard.tibbett@orange-ftgroup.com
- Cc: public-device-apis@w3.org, schitturi@rim.com
- Message-ID: <1264682398.25189.417.camel@happy.home.mcmillan.net.nz>
On Fri, 2010-01-22 at 15:10 +0100, richard.tibbett@orange-ftgroup.com
wrote:
> Hi,
>
> The first editor's draft of the Calendar API is now available:
>
> http://dev.w3.org/2009/dap/calendar/
>
> Suresh and I collaborated closely to produce this draft. It goes without
> saying that this draft does not yet represent the concensus of the group
> (first editor's draft's really are just that).
>
> We look forward to further discussions on the mailing list in the coming
> days.
Hi,
I have to chime in with the others: the data model outlined in this
draft specification seems likely to fail to interoperate well with other
external calendar data models due in particular to:
- Loss of timezone information
- Limited recurrence capability
- Poorly considered transparence
I hope these issues can be resolved, and it is good that we're
commenting on a specification now :-)
Going through the whole draft approximately from beginning to end, I
have some more specific thoughts (and expansion on the above criticism),
as follows:
CalendarEventProperties attributes
attribute DOMTimeStamp start
attribute DOMTimeStamp? end
As someone else pointed out earlier, storing these in UTC can be
lossy. iCalendar allows for both floating time (e.g. remind me
to take my medication at 9am every day, regardless of timezone),
and zoned (the flight leaves LAX at
America/Los_Angeles:20100212T193000 and arrives at AKL at
Pacific/Auckland:20100214T070000 - and I intend to be on it) or
a regular telephone meeting scheduled among a timezone-spanning
group, for a specific time/timezone combination.
attribute DOMString? freebusy
The idea that the freebusy value can be set to 'outofoffice' or
'holiday' as well as the 'free' vs. 'busy' settings means that
this datum can no longer align with the schedule transparency
value in iCalendar. iCalendar uses 'transparent' and 'opaque'
to indicate whether an event shows as busy, or not, so a holiday
might be 'transparent' in order that I can schedule things on
that day and automatic schedule processing not get upset. In
iCalendar the display of freebusy is also affected by the
status, so in a freebusy query you will see either BUSY or
BUSY-TENTATIVE in the responses, and any unidentified period is
FREE.
I don't see what value 'outofoffice' and 'holiday' add to this
process that wouldn't be better handled through some other
classification mechanism, and on the other hand I can definitely
see value in iCalendar's simple binary 'transparent'/'opaque'
switch.
attribute CalendarRepeatRule? recurrence
The outlined structure will not cope with many recurrence
frequencies which really do occur, such as '3rd friday every
month' and so on.
If you don't want to take all of the baggage of the repeat rule
from iCalendar (and lose the ability to use library
implementations that are already out there) then I would tend to
drop the hourly/minutely/secondly parts of it rather than try to
reinvent recurrence in an effort to simplify it, and then fail
to be able to round-trip events from calendars in this device.
Even so I wouldn't be surprised if people did schedule
themselves an hourly or two-hourly event during the day for them
to check something which needed regular monitoring.
In the real world that's not usually enough though, and people
find that the 3rd friday in some month is Good Friday and nobody
will be in the office so once instance of the repeat event gets
moved to the Wednesday at a different time, and in a different
meeting room.
attribute DOMTimeStamp? expires
iCalendar also allows for COUNT occurrences, which can be more
efficient to process, but these are interchangeable, especially
if it isn't possible to change the time of the final instance
separately.
attribute long long? reminder
When adding events on my current phone, I typically set two
reminders (admittedly that's all the interface on my current
phone allows me :-). Sometimes I go to my computer and add a
third reminder to the event as well, so I think that reminders
should be an array. It's also nice if that reminder can specify
something about what *sort* of reminder it is... Should the
phone play the air-raid siren recording, or some gentle
chirping? So I think that the reminder should be an array of
CalendarEventReminder objects that would allow for more detailed
specification.
CalendarFindEventProperties interface
I believe the most common search is to look for events which
EndAfter date+time A and StartBefore date+time B, so possibly
some kind of shortcut to that is desirable.
The description of findEvents() refers to the function accepting
2, 3 or 4 parameters, but I can't see any reference as to what
they are.
It could well be useful to search also within the content of the
events, so perhaps searching for a text string in either of the
description, summary or location fields. Something along these
lines seems to be intended from the text, but I can't see how
you would make a call to do that.
CalendarOptions interface
Renaming CalendarOptions to CalendarFindOptions or something
else would appear to be sensible - a name like that has way too
much possibility for confusion.
attribute unsigned short page
It's not clear from the name, but I am guessing that this is a
way of requesting an offset into the search results, but that
the actual offset will be page * limit.
Perhaps it could be renamed to 'offset' and just be a numerical
index into the raw resultset after which 'limit' results will be
returned.
attribute boolean? group
Maybe some further clarification is needed, because I fail to
understand what this means.
Other notes...
I can't see a CalendarProperties interface, but it would seem to be
useful to have one in order to contain information such as event display
colour, calendar displayname, calendar visibility and so forth.
Such an interface might also allow for an application to subscribe to a
callback notification when events in a given calendar were added,
modified or removed. Having such an interface might then allow for
relatively simple implementation of a process to undertake the
synchronisation of event data with an external source.
Finally...
<rant>
While I don't think it matters what the UI for entering event recurrence
is, I *do* think it is essential that the recurrence model for the API
should support all of the elements of the iCalendar recurrence model.
Any other approach will come back and haunt us. Obviously a
synchronising application will have to retain full data external to the
pared-down structure outlined in this specification, but trivially,
suppose I load a holidays calendar that says something like:
FREQ=YEARLY;BYMONTH=12;BYMONTHDAY=25,26,27,28,29;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=1,2
then I want to see that two-day holiday displayed correctly.
If this is a device API for *modern* devices then there *will* be ways
of synchronising data - it's something I could do on my cellphone ten
years ago and I'm unlikely to want to stop - so the ability to
interoperate is going to be a critical success factor for this.
At present the standard for interoperation is iCalendar, so recurrence
needs to be capable of describing all of the things the iCalendar
recurrence can and in the interests of simplicity and library
reusability that very likely means using it as-is. Warts and all, if
you view it as something ugly.
Furthermore, since the event start/end are almost always an element of
the recurrence definition, the floating / set / UTC timezone model from
iCalendar must come too.
</rant>
Cheers,
Andrew McMillan.
------------------------------------------------------------------------
http://andrew.mcmillan.net.nz/ Porirua, New Zealand
Twitter: _karora Phone: +64(272)DEBIAN
Long life is in store for you.
------------------------------------------------------------------------
Received on Thursday, 28 January 2010 12:40:57 UTC