20181126 Community Meeting Minutes

Time: 10:00-11:00 UTC (11:00-12:00 CET, 05:00-06:00 EST, 21:00-22:00 AEDT)

Location: Join Zoom Meeting https://zoom.us/j/573322038

Minutes

Ewout found out it's possible to stream to Youtube directly from Zoom, but he's too old for Youtube to understand how to create a channel. Marco thinks we should still persist and make this work. Ewout will try harder.

Let's try to get it done in 1.1 (just before Christmas)
Brian will work through issues this week
Michel will work on the snapshot generator this week
Marco is starting to work on the integration of the 1.0 changes next week
Marco is going to change the FHIR .NET API pipeline to build and test Vonk for each update of the API.

Brian will pull WebApi into a separate repository.
Open question is: will we try to converge on a set of interfaces that can be used in Spark and Vonk too. And what about the interfaces in the Microsoft open source server? The WebApi stuff is based on the old Spark code, Microsoft and Vonk have started from scratch. These last two use the pipelining mechanism to componentize the servers. Ewout to set up a targeted meeting to discuss these different interfaces.

The enumerations will change over time - does that mean our generated enumerations are useless? Because if you want to parse newer normative things with older parsers you will need to be aware to configure the parsers to allow unknown enumerated types -> this means you cannot always depend on the enum value, but have to be aware it can be stored in the backing field.
Maybe introduce an enum member that signifies that an unknown enum value has been parsed. Currently, the enum will be null (which can also be interpreted as not being present in the instance data). Is it better to flag that explicitly? .DetectedUnknownEnumerationValueThatShouldNotBeMisunderstoodAsMissingData?
In general we should create a section in the docs on dealing with newer data for normative parts of the POCO's. (member may get removed, added, enums expanded upon etc.). Brian will help.

E.g. issue 495: https://github.com/ewoutkramer/fhir-net-api/issues/495 - this breaks the interface.
We decide to only change this in R4, and stick to current behaviour in 2+3. Since R4 has not yet been published under 1.x, this is not a breaking change of the interface.
We could update the generation of these properties for DSTU2+3 when we go to 2.0 of the API.
In general: we need to be able to flag tracker items that require a breaking change, but are not urgent enough to immediately implement. So, like this we can batch up breaking changes for when we are going to do a new major release. Ewout will add a label to the GitHub project.

Brian: No. It's quite some work for no direct benefits.
But this means that when we decide to change POCO generation, we'll have two different mechanisms we need to update, one for DSTU2/3 and one for R4 and later. Is that OK?
Brian indicates that this is doable for now. Also, between 2 and 3 the .tt files are already sufficiently different that you cannot port changes forward anyway.