Stream: conformance
Topic: Changing to how slicing works for element[x]
Grahame Grieve (Feb 14 2018 at 07:26):
@Michel Rutten I have committed the specification changes for GF#12259. I'm now starting to work on the snapshot generator changes for it
Grahame Grieve (Feb 14 2018 at 23:02):
.. and it's just too much work. I'll get back to it. But we'll have to think very carefully about how this works - it's basically a breaking change for the tooling across versions
Michel Rutten (Feb 15 2018 at 10:14):
Hi @Grahame Grieve, I think that the current .NET API snapshot generator for STU3 (& Forge) implement most of this behavior already. However Ewout will probably have to update the .NET validator for R4 according to the new rules.
Grahame Grieve (Feb 15 2018 at 10:52):
I don't know whether I'm going to get the change done; I've just run into a couple of other massive changes
Michel Rutten (Feb 15 2018 at 11:06):
If you'd like, we could create/identify some useful (STU3) test profiles, then generate and compare our snapshots, to identify any remaining differences/ambiguities.
Grahame Grieve (Feb 15 2018 at 12:00):
well, we already have the snapshot test suite. I wish that you guys would use that test suite
Michel Rutten (Feb 15 2018 at 12:07):
Indeed, we should. I submitted a change request, to remind myself:
https://github.com/ewoutkramer/fhir-net-api/issues/539
Ewout Kramer (Feb 15 2018 at 12:58):
Hi @Grahame Grieve, I think that the current .NET API snapshot generator for STU3 (& Forge) implement most of this behavior already. However Ewout will probably have to update the .NET validator for R4 according to the new rules.
Do we? The validator does not, but since you are maintaining the snapshotgenerator, you probably are more aware of what needs to be done!
Michel Rutten (Feb 15 2018 at 13:04):
@Ewout Kramer, if I remember correctly from a while ago when I updated this logic, Chris' proposal introduces breaking changes in the _interpretation_ of type slices, but does not affect the rules for merging constraints in snapshots. For example, constraints on value[x] are merged with base profile constraints on value[x], and constraints on valueBoolean are merged with base constraints on valueBoolean. Also, the snapshot generator emits element id's for type slices of the form "...value[x]:valueBoolean", conforming to Chris' proposal.
Ewout Kramer (Feb 15 2018 at 13:14):
Maybe...but you could now get valueBoolean, valueString, value[x] - if you already implemented that....that's nice....but also means the snapshot generator would be able to generate snapshots that the validator would not know how to handle currently...
Grahame Grieve (Feb 15 2018 at 13:16):
I documented it as nothing to do with slicing
Ewout Kramer (Feb 15 2018 at 13:22):
The gForge tracker says: "Type choice elements are treated as being implicitly sliced by type" - I guess Michel was referring to that.
Michel Rutten (Feb 15 2018 at 13:26):
Forge STU3 already allows you to define type slices and specify separate (child) constraints per type, so I guess that part is also covered. However currently when you slice an element, Forge hides the default child elements, so you cannot author constraints on children of the slice introduction element. Instead, Forge displays concrete named slices as child nodes of the slice introduction. This is a UI design issue, currently we deliberately hide some complexity to keep the application somewhat "user friendly". Still thinking about how to introduce this functionality without cluttering the UI and/or confusing users.
Grahame Grieve (Feb 15 2018 at 20:16):
I know the task talks about slicing, but once these changes have been made, there's no reason to connect constraining choice types with slicing
Chris Grenz (Feb 16 2018 at 03:39):
Disagree - you can't slice a value[x] - it's already sliced. You must reslice one of the specific types (valueBoolean/myReslice).
Michel Rutten (Feb 16 2018 at 14:59):
The proposal states: "Type choice elements are treated as being implicitly sliced by type".
Does "implicit" imply that choice type element definitions in core resource definitions will NOT explicitly specify a slice component, however processing logic should act like there is a slice component with discriminator = "type"?
Grahame Grieve (Feb 16 2018 at 19:54):
they will not explicitly specify slice components. And neither will profiles
Last updated: Apr 12 2022 at 19:14 UTC
