Stream: implementers
Topic: cardinality of root elements
Georg Fette (Dec 11 2018 at 09:07):
Hello, In all official profile StructureDefinitions the root elements have a min-max-cardinality of 0-*. What is meant with this information ? What would happen if I had a custom profile with a different min-max-cardinality ? As the cardinality of all elements is always given when they are used, the information in the root elements seems redundant, if not possibly contradicting to its possible uses as elements.
Ewout Kramer (Dec 11 2018 at 13:42):
In a StructureDefinition for an extension, this cardinality is used to indicate whether the extension may be repeated.
Lloyd McKenzie (Dec 11 2018 at 15:57):
The cardinality of the root element places limits on what the cardinality can be when referencing that type. So if you define an extension whose root cardinality is 0..1, you're not allowed to reference it with a cardinality of 0..*.
Ewout Kramer (Dec 11 2018 at 16:17):
There is a difference between @Lloyd McKenzie and my interpretation - and I cannot find a normative statement in the specification about this. Would you know where Lloyd?
The main difference between our viewpoints is that for me cardinality is enforced at validation time - so dependent on what actually appears in an instance, while for Lloyd it places restrictions on profiles that reference other types (including extensions). I agree this should also be done by authoring tools, but it means that unprofiled resources, that reference an extension with a cardinality constraint, go unchecked.
Lloyd McKenzie (Dec 11 2018 at 16:33):
I think the rules apply both for profiles and for instances. If you reference an extension, you're intrinsicly bound by the profile that defines that extension. I'm not sure where in the spec it would be defined though. @Grahame Grieve ?
Michel Rutten (Dec 11 2018 at 16:46):
Note: the implementation of the snapshot generator in the .NET FHIR API library confirms to Lloyd's interpretation. In other words, if a profile element references an external type profile, then the cardinality of the referencing element is constrained by the cardinality of the referenced root element in the external profile. Optionally, the referencing profile can further constrain (but not relax) the inherited cardinality.
The snapshot generator logic simply applies any inherited constraints by overriding, but does no attempt to verify the actual values. It is up to the validator to verify that the applied constraints are actually valid.
Grahame Grieve (Dec 11 2018 at 19:59):
technically, what we say is that it has no meaning:
min/max optional (irrelevant)
Grahame Grieve (Dec 11 2018 at 19:59):
http://build.fhir.org/elementdefinition.html#interpretation
Grahame Grieve (Dec 11 2018 at 19:59):
but I do agree with Lloyd's interpretation
Georg Fette (Dec 11 2018 at 21:02):
ah, thank you. Interesting to see that the answer was already there in the specs :-)
Lloyd McKenzie (Dec 11 2018 at 22:09):
Added GF#19756
Chris Grenz (Dec 18 2018 at 23:51):
This is exactly why we included what's in the spec today. The snapshot generator (and validator) is not supposed to pull the root element cardinality into the element snapshot - it's supposed to ignore the root element cardinality.
Lloyd McKenzie (Dec 18 2018 at 23:58):
If the root cardinality of an extension definition is 0..1, it's illegal for a profile that references the extension to have a cardinality of 0..*
Lloyd McKenzie (Dec 18 2018 at 23:58):
The root cardinality can't be ignored.
Lloyd McKenzie (Dec 18 2018 at 23:58):
But it can be constrained
Chris Grenz (Dec 19 2018 at 00:06):
That's not what the spec says...and not what my implementations have done. Generally, I've not found it good practice to allow a type definition to constrain it's parent's ability to use it...
Chris Grenz (Dec 19 2018 at 00:07):
although I'm aware that's what SD.context does...
Lloyd McKenzie (Dec 19 2018 at 00:10):
If you have an extension that's not allowed to repeat, the extension definition needs to be able to enforce that. That's always been the rule. The change request is to ensure it's properly documented.
Lloyd McKenzie (Dec 19 2018 at 00:11):
We don't have a whole lot of use-cases for constraints other than prohibiting extension repetition, but that's still a necessary and valid one.
Chris Grenz (Dec 19 2018 at 01:19):
Is there somewhere in the spec that confirms your assertion? Extension definitions are simply type profiles. They're only special because they're implicitly applied via the url attribute. Is it your intention that this would also apply to say, a profile on Identifier?
Chris Grenz (Dec 19 2018 at 01:22):
(deleted)
Lloyd McKenzie (Dec 19 2018 at 01:50):
If someone creates a profile on identifier that has a cardinality of 0..1 (e.g. a profile for a particular MRN), then yes, that would apply. You could define in the profile a requirement that the cardinality of the declaring element would have to be a proper constraint on the profile of the type. And there are places that might be reasonable to do.
Ewout Kramer (Dec 19 2018 at 21:35):
If the root cardinality of an extension definition is 0..1, it's illegal for a profile that references the extension to have a cardinality of 0..*
That was my interpretation too. My point was not so much about what happens or can be done when authoring profiles, but more what happens in an instance. I can have a resource instance that does not claim conformance to any profile, yet the instance can use an extension, in fact, if it has multiple repeats of an extension, and the extension referenced then says 0..1 in the root - should't the validator complain?
Lloyd McKenzie (Dec 20 2018 at 01:26):
The validator could but that would mean inferring (and possibly locating) the extension profile based on the url. That's not magic we've assumed just yet.
Last updated: Apr 12 2022 at 19:14 UTC
