RE: CfC: Calendar FPWD

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.

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

------------------------------------------------------------------------


---------------------------------------------------------------------
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 Thursday, 11 March 2010 22:45:20 UTC