Skip to content

20190415 Community Meeting Minutes

Ewout Kramer edited this page Apr 30, 2024 · 1 revision

Time: 10:00-11:00 UTC (11:00-12:00 CEST, 05:00-06:00 EST, 19:00-20:00 AEDT) Location: Join Zoom Meeting https://zoom.us/j/573322038

Minutes

  • Luke is still working on backport of changes to stu3. His PR is not only scoped to .NET4 anymore but also contains improvements to tests and other bits in the project files. Marco and I are looking at the impact of pulling it all. It does contain #ifdef for .NET4, which are necessary but also meanns we're having more conditional code.
  • We need to decide what to do with the non-POCO parts (ElementModel, FhirPath, ...) with regards to DSTU2. People running DSTU2 + STU3 + R4 side by side will currently need to use a single (shared) version of ElementModel/FhirPath etc. If we don't maintain DSTU2 anymore, but DO change the (binary) interface of these non-POCO libraries, we will get runtime failures in DSTU2. It's very probably we will break binary compat at some point, so this means we'd have to maintain (at least recompile, maybe even fix errors) DSTU2 and keep on shipping it. This is not what we want. So we probably need to ship one more version of the DSTU2 library with DSTU2-specific versions of these libraries (just a change of assembly/nuget package IDs), which basically serve as a snapshot of the current version, so we can develop truly independently. In that case Brian, Martijn and other can simply load multiple versions of these libraries.
  • Brian asks if we can ship a few more changes to DSTU2 that are different from STU3/R4. We will review the pull request to determine the impact. We all agree we do not need to port back new functionality in any case. Brian also offers to maintain the DSTU2 and port the most necessary changes forward until we ship the 1.3 version and thus a new "frozen" set of DSTU2 libraries.
  • We will soon pull George's PR for splitting of the shared code (the basics)
  • As for going further with splitting of Resource: George thinks that moving Resource to the shared code will cause a breaking change in the public interface. Mostly around the methods for running the invariants. The question is: can we do that in the 1.x release, or wait until 2.0? George also made the comparisons between STU3+R4 and most differences are minor, mostly serialization order and new elements.
  • Removing the code for running the invariants in the Resource needs to be removed to be able to extract Resource, and it would clean up Resource too. The invariants also depends on functionality that pulls in lots of other poco-dependencies.
  • We will determine outside of this meeting how impactful the changes for the invariants on Resource are. Most likely we need to wait to 2.0 - which means the PR George is working on will need to be updated with the changes since now. Better to pauze work on that branche until we know how to move forwards.
  • Marco has started to work on the Validator: breaking it up into smaller blocks to make it more re-usable. Marco has been doing a try-out by splitting off some of the basic validations (min/max/pattern, etc).
  • Ewout and George will not be around the next call.

Action items

  • Luke: backport changes to stu3 ** Brian: PR for the develop branch to 1) remove web api code, 2) add some functionality from web api that is useful for the core API.
  • Brian - generate an implementation of ISummaryDefProvider
  • Brian will do an experimental run on code generation of an "unknown code" in all enums.
  • Brian has pulled out the Web.Api stuff from the repo to new repo https://github.com/brianpos/fhir-net-web-api, just needs to be removed from the API repo.
  • Brian/Kenneth to set up a targeted meeting to discuss these different interfaces for WebApi. Ewout to send contact details of interested parties (Vonk, MS, Kenneth, BrianP, Mottini).
  • Ewout to schedule a meeting to show proposed changes to the internals of the validator [DELAYED until further notice]
  • George creating an issue to sync the IBackboneElement/FhirType(namedBackboneElement) approaches
  • Ewout will turn the requirements for the new validator in his OneNote into a wiki page.
Clone this wiki locally