Re: [calsify] WGLC JSCalendar

[Michael Douglass <[e-mail]>]

On 10/25/19 02:08, Neil Jenkins wrote:
>>> Yes, this is intentional. The property context is different between 
>>> them and they have different definitions.
>>
>> I'd prefer one of them had been called scheduleStatus. Can't validate 
>> the value without the context
>>
>
> I think you're always going to need the context to validate properly. 
> The status property in RFC5545 
> <https://tools.ietf.org/html/rfc5545#section-3.2.12> is basically the 
> same. It's not really the scheduleStatus, it's the event/task status.
>
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.