Stream: conformance
Topic: Slice Cardinality Confusion
Chris Moesel (Oct 04 2021 at 21:52):
According to 5.1.0.12 Slice Cardinality:
When an element of a fixed cardinality m..n is sliced, the following rules apply:
- Each slice cannot have a greater cardinality than the maximum number of slices allowed
I'm having trouble understanding what this rule means. What is a "greater cardinality"? Is that in terms of min or max? And does it really mean to compare to "maximum number of slices allowed" (because I don't understand how the number of slices is relevant)? Or does it mean "maximum number of items allowed in the sliced element"?
Jean Duteau (Oct 04 2021 at 23:24):
i would interpret that as saying the slice cardinality can't be greater than n. So you can't say identifer = 0..1 and then slice it and say that slice X must appear 2 times.
Grahame Grieve (Oct 05 2021 at 00:23):
almost - slice max can't be greater than element max
Chris Moesel (Oct 05 2021 at 12:09):
OK. We actually implemented SUSHI that way. We emit an error if your slice max is > your element max. But... We received requests to remove the error because a profile of a profile might zero out a sliced element that was inherited from the parent -- in which case you'd be forced to go through and zero out all the inherited slices too (which is annoying). Apparently the IG Publisher allows slice max > element max, so they thought it was an allowable situation. I was on board w/ removing the error until I saw the bit in the spec that I quoted above.
Any thoughts on this, @Grahame Grieve? It sounds like the spec requires that if you zero out a sliced element, you must also zero out all the slices. Since this is tedious, I'm thinking about having SUSHI automatically do it for you.
Simone Heckmann (Oct 05 2021 at 12:23):
Wait. But if you have a sliced optional element with 0..n which has two optional slices with 0..1 each.
That means you can't decide, say, in a derived profile, that you don't want the optional element at all and constrain it to 0..0, because n > 0 ?
Chris Moesel (Oct 05 2021 at 12:31):
You can mark the element 0..0. That's fine. But then you should also mark its slices as 0..0 since they are no longer optional (they are now prohibited since the whole array is prohibited).
Lloyd McKenzie (Oct 05 2021 at 13:32):
If there's a slice that's 1..5 in a parent profile, you can't make it go away in a child profile. You can't ever make the overall element 0..0.
Lloyd McKenzie (Oct 05 2021 at 13:44):
The defacto minimum cardinality is the sum of the minimums of the slices
Lloyd McKenzie (Oct 05 2021 at 13:44):
You can't constrain the overall max below that minimum
Lloyd McKenzie (Oct 05 2021 at 13:45):
Slice cardinalities must always be satisfied. It's not a situation of "if you have this element, then you must meet these cardinalities".
Patrick Werner (Oct 05 2021 at 13:59):
ugh thats inconvenient :sad:
I saw several use-cases were the derived profile constrained the sliced element to 0..0 to express: "we don't need/use that"
Chris Moesel (Oct 05 2021 at 13:59):
@Lloyd McKenzie - agreed on all points. I think the main issue of confusion here was related to max cardinality. If you say an element can have at most n items, and then you define a slice saying it can have at most n+1 items, then that slice max can never actually be achieved without violating the overall element cardinality.
Patrick Werner (Oct 05 2021 at 13:59):
After your input this would mean, that these usecases would have to create their own "alligned" profile to do such things.
Patrick Werner (Oct 05 2021 at 14:00):
thanks @Chris Moesel for keeping track of the actual issue. The issue was only max card. related.
Patrick Werner (Oct 05 2021 at 14:01):
Chris Moesel said:
You can mark the element
0..0. That's fine. But then you should also mark its slices as0..0since they are no longer optional (they are now prohibited since the whole array is prohibited).
Patrick Werner (Oct 05 2021 at 14:02):
I think this needs a test case for the validators, currently the java validator allows only setting the element to 0..0
Lloyd McKenzie (Oct 05 2021 at 14:19):
Agree that the validator should catch and prevent this. Care to submit a Git issue?
Richard Townley-O'Neill (Oct 05 2021 at 22:54):
Patrick Werner said:
ugh thats inconvenient :sad:
I saw several use-cases were the derived profile constrained the sliced element to 0..0 to express: "we don't need/use that"
With luck, the derived profile can leave the sliced element not marked must support, then it can be ignored in implementations.
Lloyd McKenzie (Oct 06 2021 at 00:50):
Well, except sender must satisfy cardinalities regardless of how things are marked
Patrick Werner (Oct 07 2021 at 08:59):
Lloyd McKenzie said:
Agree that the validator should catch and prevent this. Care to submit a Git issue?
https://github.com/hapifhir/org.hl7.fhir.core/issues/616
Last updated: Apr 12 2022 at 19:14 UTC
