20190902 Community Meeting Minutes

Update on the stu/common split

• We did the split after we published 1.3 of the API. It means we have two repos, we work from github/fhir-net-api, but it has a submodule in github/fhir-net-common.
• Tests that have specific references to STU materials (use the POCO's) - remained in the non-common parts.
• Still, there is quite a bit of code in the STU-specific bits that CAN be moved, but this is ongoing work. Even more could be moved when we manage to get Resource into common.
• If your fork does not have substantive changes on code that we now moved to "common", you'll just get a new subdirectory "common", which is a submodule. And of course you need to understand submodules.
• TODO: It would be nice to have a page with some links we used to learn about it, to support people who have forked.
• TODO: How do we keep track of who is moving stuff from STU->commom? Let's make a wiki page to discuss, and then create issues for each real activity.

1.x / 2.x discussion

• Straight after we split off common, we started working on "2.0". And so "develop(-stu3/-r4)" contain work that will be released as "2.0" and will contain breaking changes. These breaking changes are documented here: https://github.com/FirelyTeam/fhir-net-api/wiki/Breaking-changes-in-2.0.
• TODO: Brian would like a 2.0-alpha before work is paused because of my sabbatical
• TODO: We want to switch the generator backend for FhirPath to Linq.Expression. Find out whether code generation Linq.Expression.LambdaExpression.Compile() work under UWP (or MacOS)?
• There are several big tasks we will start under the "2.x" moniker:
  • Make FhirPath engine support the Normative version. Status: about 100 tests or so still failing. Need to write better (implicit) system of casts and add new math functions mostly. Not sure this can be done pre-sabbatical.
  • Split up the validator for more flexibility and configurability - Marco is in design phase for this
  • FhirClient refresh - George has split up the client into a layer POCO->ITypedElement->Http. Also, this will allow better unit-testing of the layers above http.
• All of these need (minor?) changes to the public API, so need a new major version. Publish them all at one in one go? Probably better to publish them as we finalize each separately. Easier for people to follow along and adapt their software, instead of waiting for the big bang...

1.x work items

• There is still a set of branches for doing bugfixes -> 1.x/dstu2, 1.x/stu3, 1.x/r4.
• This has been branches off after the split, to easily merge changes from 1.x -> 2.x
• EK will try to re-integrate better slice validation into 1.x and rework validation.
• GS work on the reported other bugs

Work items

• Who?: It would be nice to have a page with some links we used to learn about it, to support people who have forked.
• Ewout: How do we keep track of who is moving stuff from STU->commom? Let's make a wiki page to discuss, and then create issues for each real activity.
• Ewout/Marco: Brian would like a 2.0-alpha before work is paused because of my sabbatical
• Who?: We want to switch the generator backend for FhirPath to Linq.Expression. Find out whether code generation Linq.Expression.LambdaExpression.Compile() work under UWP (or MacOS)?
• Kenneth: Discuss changes to terminology service interface
• Brian - generate an implementation of ISummaryDefProvider
• Brian will do an experimental run on code generation of an "unknown code" in all enums.
• 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).
• Marco/Ewout to schedule a meeting to show proposed changes to the internals of the validator [DELAYED until further notice] *George creating an issue on github to sync the IBackboneElement/FhirType(namedBackboneElement) approaches