Stream: conformance
Topic: More about Slicing
Grahame Grieve (Jul 30 2019 at 00:58):
See this thread: https://chat.fhir.org/#narrow/stream/179239-tooling/topic/IG.20Publisher.20-.20Inconsistency.20in.20displaying.20snapshot
Grahame Grieve (Jul 30 2019 at 00:59):
- the base profile slices an element (open, disciminated by a sub-element)
- it defines some constraints on all slices
- it defines one slice with a constraint on the sub-element
Grahame Grieve (Jul 30 2019 at 00:59):
- the derived profile imposes a must-support on the element
Grahame Grieve (Jul 30 2019 at 01:00):
it doesn't say anything about slicing. It presumably means that the must-support applies to the element, and therefore to all the slices defined on the element. I'm not sure we've discussed this particular scenario?
Uday Chandrupatla (Jul 30 2019 at 01:26):
@Grahame Grieve Just wondering should it be a candidate for GForge?
Grahame Grieve (Jul 30 2019 at 01:27):
not at the moment. Don't know what the issue is
Grahame Grieve (Jul 30 2019 at 01:28):
there's a really thorny thing here - the implication is that a given element has 2 ancestors, and I don't know how to make that work
Michel Rutten (Jul 30 2019 at 08:36):
Trying to understand the scenario. Is this about how to compute/validate the set of constraints on the named slice in the (snapshot of) the derived profile?
Grahame Grieve (Jul 30 2019 at 09:52):
No it’s about how to generate the snapshot in this case
Michel Rutten (Jul 30 2019 at 10:08):
FYI, the .NET SnapshotGenerator does NOT try to merge constraints on slice introduction with constraints on named slices. If a resource element matches a named slice, then I assume that the validator verifies the element against the constraints for the matching named slice, and also against any common constraints specified by the slice introduction element.
Michel Rutten (Jul 30 2019 at 10:10):
I remember that we have discussed merging common constraints specified by a slice group onto all named child slices, however I never got around to actually implementing this behavior in the .NET SnapshotGenerator. This is very hard to support in Forge, as the application would need to harmonize live changes to slice groups to all child slices. Theoretically possible, but quite hard in practice, especially gracefully dealing with all kinds of boundary conditions (i.e. report/merge conflicting constraints?).
Grahame Grieve (Jul 30 2019 at 10:18):
I think it’s really complex. Imagine that the child profile profiles the unsliced element, and it also profiles the slice. The slice now inherits properties from 3 different elements - in what order? Nuts....
Grahame Grieve (Jul 30 2019 at 10:18):
From a tooling point, we should say that if the base slices, then the derived profiles have to constrain the slices as well as the unsliced
Michel Rutten (Jul 30 2019 at 10:23):
Indeed. By not merging slice group constraints onto named slices, the .NET SnapshotGenerator completely ducks the multiple-inheritance issue - instead, leaving it up to the validator. This shifts more work to validator implementations, but also allows validators to report on potentially conflicts between constraints from different origins (slice group vs. named slice).
Michel Rutten (Jul 30 2019 at 10:25):
SnapshotGenerator implementations always need to merge constraints in a specific, well-defined order. However validators can verify an element against any number of constraint sets, in any order and simply report all violations.
Grahame Grieve (Jul 30 2019 at 11:36):
hah. the validator doesn't handle must-support, which is the question here.
Grahame Grieve (Jul 30 2019 at 11:37):
@Uday Chandrupatla - what you're trying to isn't going to be supported - you have to put must-support on the slice too
Chris Grenz (Jul 30 2019 at 13:32):
If your snapshot builder doesn't handle multiple parents, how do you handle the multiple type.profile constraints? Yes, absolutely there are multiple "parents" for an element:
- the "local" parent - the slice parent in this profile
- the "base" parent - the same slice in the base profile
- the "type" parent(s) - the element in any attached type profiles
The "path" of snapshot aggregation will weave it's way thru these.
Chris Grenz (Jul 30 2019 at 13:34):
@Ewout Kramer @Michel Rutten @Grahame Grieve ^^
Michel Rutten (Jul 30 2019 at 13:55):
@Chris Grenz, the .NET SnapshotGenerator aggregates element constraints from:
1) associated element in the base profile (if any)
2) external type profile, specified by the element itself or inherited from base element
3) any other constraints specified by the element itself
In the specified order, from lowest to highest priority.
As I mentioned before, the .NET SnapshotGenerator (and Forge) does NOT aggregate common constraints specified on a sliced element onto the associated concrete named slices. Assumption is that validators will verify slice elements in a resource instance against both sets of constraints; (1) common constraints specified by the slice intro and (2) specific constraints specified by a matching named slice.
Chris Grenz (Jul 30 2019 at 14:02):
What about sub-slices (reslices)?
Chris Grenz (Jul 30 2019 at 14:04):
And multiple type profiles?
Michel Rutten (Jul 30 2019 at 14:19):
According to the spec about .type.profile and .type.targetProfile, "one must apply":
http://hl7.org/fhir/elementdefinition.html#definition
Also:
http://hl7.org/fhir/elementdefinition-definitions.html#ElementDefinition.type.profile
"If any profiles are specified, then the content must conform to at least one of them."
The .NET SnapshotGenerator only aggregates constraints from a single type profile, not if an element specifies multiple type profiles.
Michel Rutten (Jul 30 2019 at 14:21):
Re-slices aggregate constraints similarly:
1) associated (re)slice element in base profile
2) external type profile
3) other constraints specified by the reslice element itself
Michel Rutten (Jul 30 2019 at 14:23):
(FYI if I recall correctly, implementing support for reslicing did not require a lot of custom logic. Mainly to find the correct matching base element. However constraint aggregation is similar/equal.)
Chris Grenz (Jul 30 2019 at 14:23):
I think that's ok for validation constraints, but I think it's broken for the descriptive elements.
Michel Rutten (Jul 30 2019 at 14:27):
Might be... Must confess that I have yet to find a real-life end user scenario that requires complex, deeply nested aggregation/concatenation of descriptive constraints. Many profiles we see in the wild do not specify any user-readable content at all :/
Chris Grenz (Jul 30 2019 at 14:57):
You haven't had me as a client very long yet! ;)
Last updated: Apr 12 2022 at 19:14 UTC
