Stream: implementers
Topic: Restricting cardinality to 0..0
Travis Stenerson (May 17 2018 at 14:07):
Could someone verify if I've understood this correctly:
When you restrict cardinality in a profile to max: "0", which interpretation is correct:
"My system will not accept the resource with this attribute"
or is it
"My system will not ever return the resource with this attribute"
or
"My system will accept the resource with this attribute, but we will not use or persist the attribute, though the rest of the resource can be persisted"
Or am I completely off?
Thank you
Josh Mandel (May 17 2018 at 14:13):
Restricting the cardinality is something you do in a profile. Now, there are various ways for systems to describe their relationships with and conformance to profiles. For example:
-
List it in
CapabilityStatement.rest.resource.profile: this indicates restrictions on data the server takes (as input) and returns (as output). All resources of this type must meet the profile. (Now, on incoming data, the server _could_ decide to turn invalid data (containing the prohibited element) into valid data (e.g. by stripping the prohibited element), but it would need to be really sure that was safe. I'm not sure I'd recommend it.) -
List it in
CapabilityStatement.rest.resource.supportedProfile: this indicates that the profile is supported by the server, meaning that the server expects to expose or consume some data according to the profile -- but it needn't apply to all resources of the indicated type.
Lloyd McKenzie (May 17 2018 at 14:33):
It is intended to represent the former for sure. It can be used to indicate the second, though that can also be indicated by just marking the element as mustSupport=false. The third is handled by mustSupport=false.
Lloyd McKenzie (May 17 2018 at 14:33):
As a rule, only constrain max cardinality if it's an error for the data to exist and it's not something you can just ignore and throw away.
Travis Stenerson (May 17 2018 at 15:29):
Ok great, thanks guys.
Last updated: Apr 12 2022 at 19:14 UTC
