Request to make Meta required on IcarEventCoreResource and SourceId on Meta required

[DavidJeppesen-Seges]

Hello

I would like to discuss whether the meta field on icarEventCoreResource.json should be required and whether the sourceId field on icarMetaDataType.json should be required.

While we have made the decision that all our POST endpoints receives a list of events, we require the ability to reply back on each event individually. The client should then use the sourceId field to match responses with requests, so when realizing this, it is very much required.

Looking forward to hear your thoughts on this.

[cookeac]

We agree - for those of us who are using meta.source and meta.sourceId to keep data and identity synchronised between systems, these fields are very much required. They were not initially required in the specification, so they have not been marked as required to avoid breaking existing implementations but the specification for the POST methods makes it clear these need to be used.

[cookeac]

Meeting 2023-03-09:

• Yes, we would like to make meta and meta.source and meta.sourceId required fields.
• Most systems would have an ID to populate these (even the event ID or animal Id).
• This is a breaking change - would have to be notified in advance.
• We need a mailing list of active users - suggest reaching out through ICAR and contacts to add people.
• Such a mailing list would be useful to gather feedback as well.

[cookeac]

I have activated the Github Discussions feature for our Repo initially. This is helpful because it lets anyone see more about an announcement or a discussion, but it is not clear to me that people can (for instance) subscribe for notifications on the Announcements channel within the discussions.

[cookeac]

We tested the Discussions feature today, and found that you can either:

• Subscribe to a single discussion threat (not topic)
• Or use the GitHub "watch" feature to get emails for all discussions (which you may not want)
  In both cases, you also need a GitHub user account.

A solution is to use a mailing list. We will try this one (subscription form here): https://tinyletter.com/icar-ade

[cookeac]

Added notice to discussion #403 and will notify using the mailing list.

[cookeac]

We reviewed this again as we are approaching the release of ADE 1.4.
We remain concerned about a breaking change in a minor release, but there would be substantially more changes to make as we move to version 2.0 (see #210 and #259 for example).

Proposed approach:

• Update the documentation for meta (in icarAnimalCoreResource and icarEventCoreResource to make it clear that meta SHOULD be used if at all possible, and will be required in version 2.0.
• Update the documentation for sourceId in icarMetaDataType to make it clear that this SHOULD be filled with a value that is unique within the source (even if a composite key involving location identifier must be created) AND that systems which transfer or store this data should retain the value of source and sourceId.