ICAR Animal Data Exchange Working Group – Technical meeting 08 April 2021

• In attendance: Andreas S, Andrew C, Anton H, Craig V, Kor O

Agenda:

Items were suggested by the attendees. The focus was on closing items to allow us to publish the new release.

1. icarFeedQuantityType mass unit codes (211)
2. Naming inconsistency in icarValidSampleFillingIndicatorType (210)
3. Handling batch POST methods (relates to 154)
4. Items for next meeting

1. icarFeedQuantityType mass unit codes (#211)

Anton had suggested that rather than an inline definition of units for icarFeedQuantityType, the uncefactMassUnitsType could be used. This has been implemented in the current pull request, and the additional units PN (pounds net) and ONZ (ounce) have been added.

2. Naming inconsistency in icarValidSampleFillingIndicatorType (#210)

The ValidSampleFillingIndicatorType has values 0, 1, 2 rather than the enumeration values Success, Incomplete, Completed that we would prefer. This is a result of the original conversion from the XML schema. We agreed that this should be changed, but it would be a breaking change.

• Andrew to create a label for such changes
• The issue will be labelled and deferred until we are planning a major release.

3. Handling batch POST methods (relates to #154)

We discussed where the "/batch" identifier should be inserted in a URL, as it had been agreed that a POST to a collection URL would support a single resource only.

• Our preference was to add it after the /location/ and before the collection name

Anton showed a prototype service where:

• The client (source) could generate an identifier for events when POSTing data, but it was not guaranteed unique.
• The server would generate its own identifier and return this if the batch POST was successful.
• The client needed to match the returned items in the array back to its original POSTed items, so it could store the server-generated identifiers.
• The prototype used an additional clientReference field to achieved this.

We suggested that:

• The meta.source and meta.sourceId could be used rather than a client reference field.
• The server could fill in its id in the returned objects, and should return the supplied meta.source and meta.sourceId fields
• We recommended that the server should return the complete objects posted, with any attributes it had modified or filled in, as a result of the POST. We recognised that this could be a large amount of data with bulk posts, but would protect against future changes.

We also discussed what the return results for a PUT or PATCH might be. Andrew suggested we look at https://jsonapi.org/format/#crud and form an opinion on the utility of that approach.

Next meeting scheduled for 22 April 2021 at 8:15am CET