Re: [calsify] WGLC JSCalendar

["Neil Jenkins" <[e-mail]>]

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.