Stream: conformance
Topic: ElementDefinition Rules about Slicing
Chris Grenz (May 04 2018 at 18:08):
http://build.fhir.org/elementdefinition.html#slicing
The last bullet point is just plain wrong...I think. "The first entry (the one having the slicing information) is understood to be the set of constraints to be used for the 'open' slice" - no, that's the @default slice. If you create a constraint on "the first entry" with the slicing information, you're constraining all slices. If I'm not missing something, this is a must fix technical correction. @Ewout Kramer @Michel Rutten @Grahame Grieve @Lloyd McKenzie
Chris Grenz (May 04 2018 at 18:09):
For some reason, there's an exception for min..max in this wording??
Chris Grenz (May 04 2018 at 18:11):
I'm confident this is wrong because the first entry with the slicing definition is where all the standard constraints live (e.g. bindings), and adding slices can't remove those (make them apply only to the 'open' slice).
Lloyd McKenzie (May 04 2018 at 18:18):
Please submit a change request
Lloyd McKenzie (May 04 2018 at 18:19):
Agree it should be fixed
Chris Grenz (May 04 2018 at 18:19):
Will do. Just wanted to check that I wasn't missing something.
Chris Grenz (May 04 2018 at 18:24):
Grahame Grieve (May 05 2018 at 05:00):
the min..max exception is real and deliberate
Michel Rutten (May 07 2018 at 09:31):
@Chris Grenz agreed, this seems to be an error in the specification and should be corrected.
Ewout Kramer (May 07 2018 at 11:57):
Don't know. This was written before we had @default and it seems correct in that context: the first entry's constraints describe the constraints that must be satisfied by any instance of that element, whether it ends up in a named slice, the @default and the open slice, right? So, if the slice is open, anything that matches these constraints, but not the ones on the slices ends up in the open slice. I think that is what the current text says, though this has become somewhat ambiguous now there's a @default slice (only if the slice is closed). If the slice is closed, and you have a @default, it would still need to match these constraints, and any additional constraints the @default slice itself has. Correct? Maybe the text should just be expanded, don't think it's wrong. Unless I have misunderstood.
Chris Grenz (May 07 2018 at 13:40):
As I read it, the constraints on the first (slicing) element, which comes from the baseDefinition as an unsliced element, now only apply to instances not falling into a named slice (the "open" slice). This is not correct - all constraints including min, max, bindings, etc. found on this element apply to all instances.
I'm not sure what @Grahame Grieve is talking about? min..max on the first element constrains the total number of instances regardless of slicing. For example, if I profile CodeableConcept, and set #CodeableConcept.coding's min..max to 1..3, there can be only 1, 2, or 3 codings present in any conformant CodeableConcept, full stop. No amount of slicing or re-slicing can override that.
Ewout Kramer (May 07 2018 at 13:45):
As I read it, the constraints on the first (slicing) element, which comes from the baseDefinition as an unsliced element, now only apply to instances not falling into a named slice (the "open" slice). This is not correct - all constraints including min, max, bindings, etc. found on this element apply to all instances.
I never read that into it, but now you are saying it: I could if I wanted to ;-) Agree that it should not mean that, it's not just for the open slice.
I'm not sure what @Grahame Grieve is talking about? min..max on the first element constrains the total number of instances regardless of slicing. For example, if I profile CodeableConcept, and set
#CodeableConcept.coding's min..max to1..3, there can be only 1, 2, or 3 codings present in any conformant CodeableConcept, full stop. No amount of slicing or re-slicing can override that.
"total number of instances regardless of slicing", yes that is what the spec says too, I think the two of you agree.
Chris Grenz (May 07 2018 at 13:47):
The language of "open" slice should at least be replaced with "all instances" or something. Frankly, I think we do a much better job of describing slicing over on profiling.html and this is just muddying the water.
Michel Rutten (May 07 2018 at 14:18):
I have always interpreted slicing rules as Chris explains them. Apparently the current wording is still ambiguous, so we should try to be crystal clear.
Lloyd McKenzie (May 07 2018 at 14:27):
If you set min=1 for the overall element, that does not set min each one on every slice. It can't.
Chris Grenz (May 07 2018 at 14:27):
Ah, I understand.
Chris Grenz (May 07 2018 at 14:28):
So it's really only min that's excepted. Max would be the same (or less if specified)
Lloyd McKenzie (May 07 2018 at 14:29):
Yes, I think that's true.
Michel Rutten (May 07 2018 at 14:49):
Technically, a slice can specify conflicting cardinality constraints. For example, 1..1 on overal element and 2...2 on a named slice. This is a valid profile, however no instances will ever match. I consider this a very complicated way of describing the empty set. Like "SELECT * FROM Persons WHERE 1=0" is a valid SQL statement that will always returns the empty set. The validator could detect such conflicting constraints and emit a warning.
Chris Grenz (May 07 2018 at 14:59):
I'd suggest that it's up to authoring tooling (or any other tooling so inclined) to determine if a set of constraints are exclusive. It's up to the standard to define what's valid. A 2..2 slice on a 1..1 element is not valid in that a constraint max cannot be larger than the base . The min 2 being higher than 1 is OK, except that min must be < max, and max of the profile cannot be larger than the base.
So, in theory I agree with you, that profiles may construct empty sets, but not with your specific example. A non-overlapping binding is probably a better example, although that also may get some dissent.
Last updated: Apr 12 2022 at 19:14 UTC
