RE: CfC: Calendar FPWD

On Thu, 2010-03-11 at 16:43 -0600, Suresh Chitturi wrote:
> Hi Andrew,
> 
> You comments (i.e. adding the time zone, recurrence amendments) are
> valid. However, as stated below in the CfC, the specs need not be
> polished and perfect, but as long as it is in a state that provides the
> basic scope of the feature set, that should suffice. There is a lot more
> work to make this spec, and this is just a FPWD.
> 
> For your information, we discussed exactly this issue during this week's
> conference call on the maturity level needed for FPWD (similar to the
> issues you raised below), and it was clarified that what we have today
> in Calendar API is sufficient for the FPWD. If you prefer to add a note
> to the current draft as a place holder to capture your comments, please
> propose one, and it can be easily added. This way, you can be assured
> that your comments will be taken into account in the next draft.
> 
> Hope this clarifies a bit.

Thanks Suresh,

This clarifies things a little, but what surprises me is that I have
raised these two issues on every occasion that the Calendar draft has
been publicised to this list, and my comments on these issues appear to
go into a black hole, while my comments on other issues have been taken
on board and applied to the specification.

What gives?  If there is some problem that could be discussed in respect
of my two points then I would love to have that discussion, but that
does not seem to be happening anywhere that is visible to me, and so I
increasingly wonder if I should continue to care.

It would be appreciated if you would add notes to the spec to point out
the following:


(a) HTML5 dates do not provide sufficient information for accurate
scheduling of repeating events. The HTML5 date specification only allows
an offset from UTC, which does not contain enough information to
accurately determine the times for subsequent instances of repeating
events after crossing a DST boundary.  Specifically, the mapping of a
timezone to a UTC offset is a many to one mapping which varies over time
due to varying DST rules, and so it is impossible to reliably infer DST
boundaries on the basis of a UTC offset.


(b) To be generally useful, a system for representing repeat frequencies
must take consideration of events which occur in a manner such as the
2nd Tuesday each month (or month multiple), or the last Friday, and so
forth.

The most commonly used types of repeat frequencies are:
 * Weekly (with day of week)
 * Yearly (with month and day of month)
 * Monthly (with week number and day of week)  (Not currently handled)
 * Monthly (with day of month)
 * Daily

Other less commonly used repeat frequencies which are not handled
include:
 * Monthly (Nth day in set - e.g. first/last business day of month)
 * Yearly (ordinal day)
 * Yearly (with month, week number and day of week)
 * Yearly (week no and day of week)
 * Yearly (with month, day of month, day of week, Nth in set)

There are a number of others, in particular the 'set filter' types like
the last one, which become increasingly obscure.

I consider that it's pretty important to implement the first five types
in a consumer-facing device, and I would expect a modern UI to offer all
of them to me or I wouldn't be able to enter my schedule.  After
birthdays, the most common type of repeating event in my calendar is of
this form.

The last three listed above are less common, but they occur particularly
in the definitions of holidays.  I think it's acceptable if a device
can't handle them, because they will usually be entered into a system
that can, and can then be expanded out to create 'holiday' calendars
that could be overlaid on such a device.

On the other hand it might be better for the specification to *allow*
for the full set, and to make the implementation of the more complex
ones optional, in order that developers could choose the simpler path of
mapping this directly into existing libraries and data structures on
modern devices with the power to do the calculation.


If notes along the lines of the above are included in the spec thenm I'm
happy to +1 the FPWD.  I just don't want naive people seeing it and
thinking that (e.g.) HTML5 dates are going to work, or that events only
repeat on daily/weekly/monthly/yearly cycles.  As it reads now an
inexperienced person could fairly easily fail to see those parts as
unfinished.


Feel free to reference this, and earlier, e-mails from me on the subject
in there too... :-)

Just as a side note, I have long suffered through a series of phones
which would have been substantially more useful to me had they had the
ability to schedule events with this kind of frequency.  Now that I
finally have a phone which allowed me today to specify 'Monthly, every
2nd Friday' I can't think that I'm going to downgrade! 


Regards,
     Andrew McMillan.

> 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, March 10, 2010 1:50 PM
> To: Robin Berjon
> Cc: public-device-apis@w3.org
> Subject: Re: CfC: Calendar FPWD
> 
> On Wed, 2010-03-10 at 17:10 +0100, Robin Berjon wrote:
> > Hi all,
> > 
> > this is a call for consensus to see if there are any objections to
> > publishing the Calendar API as a FPWD. The group is aware of a number
> > of outstanding issues, and the overarching issue of whether to make a
> > Powerbox-based API is still standing, but at least some of us feel
> > that there's value in getting feedback early and often.
> > 
> > The draft can be read at:
> > 
> >   http://dev.w3.org/2009/dap/calendar/
> > 
> > Note that there is no requirement on FPWDs to be perfect - if they
> > were perfect we'd go straight to LC. They need to be good for broader
> > review, and reasonably feature-complete.
> > 
> > Where CfCs are concerned, silence is considered to be assent, but
> > positive support is preferred (even if simply with a +1).
> 
> -1
> 
> This still does not allow for accurate representation of timezones, as I
> have detailed at length in the past.
> 
> The HTML5 date specification only allows an offset from UTC, which is
> (usually) fine for the time of a specific instance of an event, but
> which does not contain enough information to accurately determine the
> times for subsequent instances of repeating events.
> 
> 
> Additionally, as I have previously also noted, the repeat specification
> does not allow for frequencies such as 'monthly, on the 2nd tuesday'
> etc, which are commonly used for specifying things like club meetings,
> user group meetings, school committee meetings and things of that ilk.
> 
> 
> I'm happy to edit and modify that specification to remedy these
> deficiencies, if that's all the problem is.
> 
> 
> Regards,
>      Andrew.
> 
> ------------------------------------------------------------------------
> http://andrew.mcmillan.net.nz/                     Porirua, New Zealand
> Twitter: _karora                                  Phone: +64(272)DEBIAN
>     I have not seen high-discipline processes succeed in commercial
>                      settings. - Alistair Cockburn
> 
> ------------------------------------------------------------------------

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