Re: [calsify] WGLC JSCalendar

[Michael Douglass <[e-mail]>]

Thanks for the changes below - I'll adjust my code and may be back with 
more on them.

I do have another concern:

5545 decided to deprecate multiple recurrence rules on the grounds 
clients (by which is meant UIs) don't support it.

This spec doesn't even make provision for it.

I've long felt that standards and data models shouldn't be driven solely 
by the needs or preferences of UI designers.

However, I also believe that multiple recurrence rules provide either a 
simpler way or the only way to express some of the situations i come 
across i public events. For example, I found a user had created 7 
identical recurring events to cover tours of a campus which occur at 
different times and with different patterns through the week. It's 
relatively easy to figure out how to accommodate that in the UI (a 
button to add another recurrence section).

It was however a lot of work to update all those events and keep them 
the same.

I've been considering supporting multiple rules to support this use case 
as I suspect it's not that uncommon.

Even when it's possible to create some complex rule it might well be 
easier to create a number of simple rules.

There's also the possibility of using standard calendar data to control 
processes.

I suspect current libraries already support multiple rules and I'd like 
to see that enabled in this spec.

I understand that if they turn up in a client they may not be able to 
render them but we're already in that position with a sufficiently 
complex single rule (often not all that complex)


On 10/27/19 20:28, Neil Jenkins wrote:
> On Sat, 26 Oct 2019, at 03:01, Michael Douglass wrote:
>> What I meant was that the objects in the list should have a type:
>>       "localizations": {
>>         "de": {
>>           "@type": "PatchObject"                    <------------------- this
>>           "title": "Live von der Music Bowl: The Band!",
>>           "description": "Schau dir das groesste Musikereignis an!",
>>           "virtualLocations/6f3696c6-1e07-47d0-9ce1-f50014b0041a/name":
>>                                   "Gratis Live-Stream aus der Music Bowl"
>>         }
>>       }
>>
>> I think patch objects are the only objects that don't have a type. I 
>> think for simplicity and ease of validation all objects should be 
>> required to have @type
>>
>
> No. The |@type| property is for objects with a named set of attributes 
> (essentially a class). The PatchObject is a primitive datatype, more 
> like Integer etc. There are no predefined keys; each key is a patch to 
> apply. So if you add |@type| there, that's actually a path to 
> overwrite the |@type| property on the object you apply it to!
>
> On Sat, 26 Oct 2019, at 03:17, Michael Douglass wrote:
>> So the status in 5.1.3 and 5.2.6 is essentially the status in rfc 5545
>>
>> Then we have participationStatus in 4.4.5 which comes from 5545 
>> partstat with
>>
>>        *  "needs-action": No status yet set by the participant.
>>        *  "accepted": The invited participant will participate.
>>        *  "declined": The invited participant will not participate.
>>        *  "tentative": The invited participant may participate.
>>
>> But we also have in 5.2.5 participantProgress with a status property:
>>
>>        *  "completed": The participant completed this task.
>>        *  "in-process": The participant has started this task.
>>        *  "failed": The participant failed to complete this task.
>>
>> Those values are essentially the partstat values from 5545 - so now 
>> we could have a participationStatus of declined and a 
>> participantProgress/status of completed which doesn't make any sense.
>>
>> I like the idea of the participantProgress object but maybe it should 
>> be common to all and the participantStatus should be moved there. The 
>> task specific part should define the allowable set of values as 5545 
>> does.
>>
>
> I agree this is confusing. Looking at it, I think the best thing is to 
> rename the "status" property on the JSTask to "progress", and use the 
> same property on a Participant (no need for a whole complex object 
> like we currently have). This makes it consistent again: the same 
> property name means the same semantics, different property name means 
> different allowed values and semantics. If that description is a bit 
> hard to follow, see the diff here 
> <https://github.com/CalConnect/PUBLIC_DRAFTS/commit/3546a6a8d9ded46185b1bb96a5a693353d16d360>, 
> or look at the diff in the new revision.
>
> On Sun, 27 Oct 2019, at 07:51, Michael Douglass wrote:
>> >> Table in section 8.2.6 appears to be missing an entry for links
>> > and locale
>> and frequency
>
> Thanks, fixed. I've also added "uri" from VirtualLocations and all of 
> the other RecurrenceRule props. I think I've checked them all now!
>
> Since there have been quite a few fixes, I've published a new draft 
> <https://tools.ietf.org/html/draft-ietf-calext-jscalendar-21> with all 
> the changes. Thanks for all the great feedback Mike!
>
> Neil.