Subject: [calsify] jscalendar and versioning

From: Michael Douglass <[email-masked]>
Date: Mon, 13 Apr 2020 12:46:31 -0400

As I attempt to define and implement mappings I've come to realize that 
it's a major mistake not to have a jscalendar version embedded in the 
data model.

We spend so much time with 5545 updates worrying about backwards 
compatibility - even though we tried to make it easier with that spec we 
still cannot change anything. Adding something is risky enough. The 
result is we stuck with a 1980s defined data model we hardly dare touch.

If we build in versioning from the start we don't have that problem. We 
still have to support older versions  (to some extent) but at least we 
know where we are.

So - when we have jscalendar widely deployed and we discover we can't 
add a feature because it means changing something - as we will - we can 
implement it as a new version of jscalendar. As long as we support the 
older version things work fine.

And assuming that no version means 1.0 isn't enough...

---

From: "Bron Gondwana" <[email-masked]>
Date: Tue, 14 Apr 2020 08:26:04 +1000

> And assuming that no version means 1.0 isn't enough...

Should it be '@type': 'text/jscalendar1' and then we can define the additional versions as new types?

Bron.

--
 Bron Gondwana, CEO, Fastmail Pty Ltd
 [email-masked]

---

From: "Neil Jenkins" <[email-masked]>
Date: Tue, 14 Apr 2020 13:06:17 +1000

> it's a major mistake not to have a jscalendar version embedded in the 

There are two big issues with adding a version number:
 1. It is likely to be "1.0" for quite some time. This means a lot of implementations will just ignore it, causing it to be meaningless should you try to update it.
 2. It's a data format not a protocol. In some contexts two parties would be able to negotiate a version, but in others (such as publishing an event more broadly) they would not. 
I think the existing extension mechanism for adding new properties is sufficient to allow future changes; should you really need to redefine the semantics of an existing property, you would instead define a new one. Up-to-date clients would generate both old and new properties (using the best semantic translation they can to the old one); older clients would ignore the unknown new property and use the old one.

Neil.

---

From: Michael Douglass <[email-masked]>
Date: Mon, 13 Apr 2020 23:23:59 -0400

On 4/13/20 23:06, Neil Jenkins wrote:
>  1. It is likely to be "1.0" for quite some time. This means a lot of
>     implementations will just ignore it, causing it to be meaningless
>     should you try to update it.
>  2. It's a data format not a protocol. In some contexts two parties
>     would be able to negotiate a version, but in others (such as
>     publishing an event more broadly) they would not.
>
> I think the existing extension mechanism for adding new properties is 
> sufficient to allow future changes; should you really need to redefine 
> the semantics of an existing property, you would instead define a new 
> one. Up-to-date clients would generate both old and new properties 
> (using the best semantic translation they can to the old one); older 
> clients would ignore the unknown new property and use the old one.

Point 1. - It doesn't have to be 1.0 for a long time. It will be if we 
never change it I guess but we should.

Point 2. I understand but in the absence of any useful version number 
how do I know what the creator of a data item intends? And in the 
absence of a useful version number what could they negotiate if the 
opportunity is there? For a simple static download of data sure - you 
may have to use the earliest version for maximum acceptability - but any 
protocol can allow for some negotiation. Even a simple GET can use accept.

Almost every change we make to iCalendar has involved us in lengthy 
discussions on whether or not something is backwards compatible - and 
that's because we never bumped the version making it useless. We've used 
all the tricks to get around this - we end us defining completely new 
properties instead of updating old ones.

>
> Neil.
>
> _______________________________________________
> calsify mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/calsify

---

From: Doug Royer <[email-masked]>
Date: Tue, 14 Apr 2020 10:14:27 -0600

On 4/13/20 10:46 AM, Michael Douglass wrote:
> As I attempt to define and implement mappings I've come to realize that it's a major mistake not to have a jscalendar version embedded in the data model.
> ...
> ...> And assuming that no version means 1.0 isn't enough...

The 1.0 in VCALENDAR is the version number of the data format. It has not changed.
I would suggest that if the jscalendar data format is something that will change over time, that the version of the data model somehow be identifiable to a parser in the data stream.

-- 
Doug Royer - (http://DougRoyer.US)
[email-masked]
714-989-6135