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

RE: [calendar] Draft updated

From: Suresh Chitturi <schitturi@rim.com>
Date: Tue, 9 Feb 2010 10:31:18 -0600
Message-ID: <D37CC1B151BD57489F4F89609F168FE8044998AD@XCH01DFW.rim.net>
To: "Andrew McMillan" <andrew@morphoss.com>, <richard.tibbett@orange-ftgroup.com>
Cc: <public-device-apis@w3.org>
Hi Richard, all,

I see that the 'reminder' property can be worked out differently than
using +ve and -ve values that I believe are non-intuitive.

My suggestion is to first create a separate interface which will allow
us to enhance/extend it further. With simply a DOMString it can be
limited on what we can do.

Proposed interface/example: 

Interface Reminder {
attribute DOMString reminderType //values: fixed, relative 

attribute DOMString fixedTime // specifies a fixed time reminder, which
can take  valid date string

attribute unsigned long relativeTime// denotes a relative time to the
start of the calendar event e.g. in minutes

};


Regards,
Suresh

-----Original Message-----
From: public-device-apis-request@w3.org
[mailto:public-device-apis-request@w3.org] On Behalf Of Andrew McMillan
Sent: Wednesday, February 03, 2010 10:45 AM
To: richard.tibbett@orange-ftgroup.com
Cc: public-device-apis@w3.org
Subject: Re: [calendar] Draft updated

On Mon, 2010-02-01 at 13:45 +0100, richard.tibbett@orange-ftgroup.com
wrote: 
> Hi,
> 
> I've made a number of updates to the Calendar API. We received a lot
of
> feedback on the first draft. For any outstanding items I will try to
> catch up on the mailing list or please feel free to bump your emails
if
> I miss something.
> 
> Updates to the current Calendar API draft [1]:
> 
> - Simply put, DOMTimeStamp has failed us. WebIDL's DOMTimeStamp object
> is too under-defined and restricted for our purposes. At the other end
> of the spectrum, ISO8601 is too flexible (has too many features,
allows
> comments, multiple formats, etc). Therefore the spec has been rebuilt
> around the Date and Time definitions provided in HTML5 [2] to allow
for
> local and global times and to include lossless timezone information.

Yes, specifying dates is complicated :-)

All of the examples seem to assume that it's OK to specify a timezone as
an offset from UTC.  I'm somewhere over the middle of the pacific as I
write this, so I can't read up on the referenced HTML5 spec right now
and check whether that's a limitation there...

While it's OK to lose the full timezone information for a single event
it becomes problematic with repeating events.  For example, a timezone
offset of +10:00 does not say whether it is for Brisbane or Sydney, and
so it does not provide sufficient data for the software to know the time
of a repeating event which crosses a DST boundary.  This is not an
uncommon feature of timezones - +12:00 is also Fiji (no DST) and New
Zealand (+13:00 in summer), and those two examples are just from the
part of the world where I live - I'm sure the situation can become even
more confusing in Europe/Africa.


> - CalendarRepeatRule has been updated to include exceptionDates and
> interval attributes.

While this is an improvement I'm not convinced that it goes very far
towards providing a useful mapping from RFC5545 RRULE.  As it stands the
specification does not allow for monthly events occurring on the 'third
tuesday' or similar constructions.

When I read this I can only think of the nightmare waiting for some poor
programmer stuck trying to map events sourced from external sources into
this in a reliable way.  A likely hack that occurs to me would be to
construct pseudo sets of events by appending an instance number to the
event id, and just duplicating the rest of the fields.  This seems
undesirable and avoidable. 

Also in RFC5545 there is a long list of example repeat rules and
explanations of what they mean, no doubt because the authors of that
specification realised it was one of the more complex parts.  It would
be great if this specification also provided examples of mapping of
those repeat frequencies (i.e. the same ones, where possible) as an aid
to developers.


> - CalendarProperties.freebusy has been renamed to
> CalendarProperties.transparency and now has the following definitions
> 'transparent', 'opaque'. Free/Busy can be inferred from a combination
of
> CalendarProperties.transparency and CalendarProperties.status as
> suggested by Andrew McMillan.

The draft still contains an example where it is called 'freebusy'.


> - CalendarOptions has been renamed to CalendarFindOptions.
> 
> - UUID has been removed as a recommendation for the CalendarEvent.id
> attribute. The only requirement is that the id attribute be globally
> unique.
> 
> 
> Hopefully that captures a small part of the feedback from last week!

Another recommendation I made in my earlier e-mail was that 'reminder'
should be made into an array of reminders.  I think it is important to
allow at least two reminders for an event, but an array seems both
simpler and more flexible.

I also suggested that reminders might also allow for some kind of
specification of the actual alarm, as one can on an iPhone, for example.

Cheers,
					Andrew McMillan.

------------------------------------------------------------------------
http://andrew.mcmillan.net.nz/                     Porirua, New Zealand
Twitter: _karora                                  Phone: +64(272)DEBIAN
        Open Source: the difference between trust and antitrust
------------------------------------------------------------------------




---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Received on Tuesday, 9 February 2010 16:32:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:32:17 UTC