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

Re: [calendar] Editor's Draft of Calendar API

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

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