-
Notifications
You must be signed in to change notification settings - Fork 27
Technical Minutes 2021 08 12
- In attendance: Andrew C, Anton H, Arjan L, Craig V, Erwin S, Peter B, Thomas D, Thomas P
First we will focus on anything that needs to be dealt with for the version 1.2 release and what we need to do to close it out. Then we will discuss items that people want to discuss for inclusion in version 1.3.
The vast majority of issues marked for this release have been closed. Just one #154 Semantics for POST method is waiting for final review and merge. Andrew C has opened some more pull requests. The earliest one is #232, the Health URL scheme, which included the examples. Most of the reviews have said it is OK and so he has done most of the other schemes (#234, #235, #236, #237, #238). Code generation has not been tested. Recommend we perform the testing.
2. Nullable declaration is not working correctly for reference types (#214)
It works fine for Java. It is not marked as nullable correctly C#.Net.
It does depend on the version of generator used.
Encouragement to use nullable true wherever we can.
There is a question of enumeration. If they do allow null values, whether we want to put null into each of the enumerations.
Needs more investigation to be explicit about whether things can be nullable.
The issue should be solved even if the bug is not on our side. We could document which works in the stated circumstances.
Anton H to investigate
Arjan L will open a new ticket related to the nullable declaration for considering moving to Open API spec 3.1. We can have a discussion there on the ups and downs. Andrew C suggested it could be the theme of version 1.3.
On the Wiki Versioning, releases and branches page, Arjan L has added how to test a version. It is a work in progress. We could extend the list of generators and add C# dotNet versions.
It will be clear which versions we have tested against. The URL scheme should not contain any resources. We should change to the different schemes we have. The URL scheme generates some server facades, the grouping of the endpoints, not all of those names are well chosen. If we now have different URL schemes, we should consider the code generation to see how it looks up those endpoints.
Arjan L also changed Implementing a service and Implementing a client application. The former includes a link to Generating code which has steps to get you up and running. It would be nice if we could add steps for C#.
Peter B reported issues with Open API generator so switched to AutoRest, open source built on Azure. It could be added to the test suite. It supports many languages.
4. New values for production purposes - Breeding, SucklerCow (#215)
There was discussion on whether the purpose should be the primary purpose or whether a multi-value array should be provided. Also the option of including secondary purposes was discussed. It was agreed to leave it as the primary purpose. The purpose of an animal may change over time. The question of the new values has not yet been resolved. This is not urgent and so can be left for version 1.3.
5. Adding 2 Types in ReproParturitionEventResource (#191)
We have already solved the question of CalvingEase. Last time we proposed a new ProgenyDetailsType, to add a new progenyDetails array, to mark the existing progeny array as deprecated and likely to remove it in version 2.0. Andrew C had suggested birthWeight, birthWeightScore and musclingScore that could be included. Alternatively birthWeightScore could be birthSizeScore. We should keep the identifiers for people who want to use them but allow them to be nullable because the progeny might not be tagged at the time they are used. We need Status and BirthStatus. There is variation between countries for BirthStatus. This is particularly with respect to the period used in the statuses where the progeny died before or after a specified number of days. Options to address this include having different schemes. We did not get resolution on this and so we will continue the discussion at the next meeting and leave it until version 1.3.
The topic for the next meeting will be doing the 1.2 version release. It would be good from a preparation perspective once the changes are merged and are OK, if we reviewed tested code generation. Then when we get to the meeting we can say we are happy to sign off the release. Andrew C has already advised that we will be doing a communication on the release.
Currently in icarAnimalCoreResource it says coatColor of the animal "is a string using the conventions for that breed". Coat color is mostly defined by the country's INR, not by the breed societies. Options include having a coat color scheme or a large master enumeration. You could have a mapping from a master list to your own list. Thomas D to add an issue and let us see what we can find in way of enumerations.
Next meeting scheduled for 26 August 2021 at 8:15am CET