Re: Feedback on Calendar API editors draft (was: Agenda - Distributed Meeting 2011-01-12)

On Tue, Feb 1, 2011 at 5:48 PM, Dominique Hazael-Massieux <dom@w3.org>wrote:

> Hi Rich,
>
> Le mercredi 12 janvier 2011 à 11:06 +0100, Rich Tibbett a écrit :
> > I spent a couple of days updating the Calendar API according to
> > ACTION-320 [1].
>
> I took the liberty to bring a few updates to the API to align it with
> recent changes to the Contacts API.
>

Awesome.


>
> Please find below further comments on the draft:
>
> The current find() function isn't quite like contacts.find() — you can't
> provide it with a list of fields/values to search for. Is that intended?
>

It was intended, however it does warrant further discussion and it was my
mistake to not highlight this change on the mailing list.

It's my belief that Calendar information does not need to be subject to such
tight privacy controls as the data minimization added to the Contacts API.
All fields in a Calendar object are somewhat connected to each other.
Obtaining only the startDate or endDate is really not ideal if a recurrence
rule has also been specified. Similarly, we're not exposing names,
addresses, phone numbers and email addresses this time around (other than,
perhaps, in the location field) so the privacy of the data is subject to
less stringent minimization techniques.

Further discussion is welcome.


> I think what's currently in CalendarEventFilter should actually be moved
> as search fields in the first parameter of the method.


CalendarEventFilter is optional hence why it is relegated to the back of the
find() method.


> There should also
> be capabilities to search for events based at least on their
> description, possibly more.
>

CalendarEventFilter extends CalendarEvent, so a web app can search for
events by any fields in that object also.


>
> I've noticed that times and dates are defined as DOMString valid in the
> HTML5 sense — this doesn't cater for the timezone-dependent needs that
> have already been discussed at length
> http://www.w3.org/2009/dap/track/issues/81
>
> Is this as a stop gap solution while you're working on defining TZDate,
> or are you actually championing this particular solution?
>

It's a stop gap solution that hasn't been updated. I'm not particularly
championing this solution since I'm pending on a workable TZDate proposal.
Alternatively I'd be happy to introduce a timezone field to the
CalendarEvent object to work around our timezoning issues. Do the timezones
specified per date field really have to be independently specified?
iCalendar doesn't seem to think so.


>
> In any case, the draft should probably include a note about that issue.


> Also, I had identified a number of missing pieces to make the recurrence
> model of the API matches what's available in iCalendar:
> http://lists.w3.org/Archives/Public/public-device-apis/2010Jul/0115.html
>
> It would be good at least to note that current limitation (or even
> better to take the required steps to fix it).
>

Suresh and I are working on revising the recurrence model so this will be
updated shortly. During the next update I'll add a note on the current
limitations.


>
> The extensibility mechanism used by the API (prefixing new properties
> with "X") isn't quite what others have been doing, where new
> properties/methods starts with -vendor- — should we align with this?
> (and do that with Contacts as well as a result)
>

In Contacts we suggest either prefixing with an X or a vendor prefix:

'Non-standard, private properties and parameters should have a prefixed name
starting with X (U+0058 LATIN CAPTIAL LETTER X) or use a vendor-specific
prefix.'

The example provided uses X but the normative text provides the real
requirements here.


>
> HTH,
>
> Dom
>

Thanks. Still many updates pending and I'll inform the group when they're
done.

- Rich