Stream: conformance
Topic: Max Size
Grahame Grieve (May 21 2020 at 00:31):
The definition of http://hl7.org/fhir/StructureDefinition/maxSize has a number of problems:
- it should be apply to any use of an Attachment, not just answers
- it should have a context of ElementDefinition not Attachment
- it should also apply to primitive types as well as attachments
Grahame Grieve (May 21 2020 at 00:31):
Does anyone disagree?
Grahame Grieve (May 21 2020 at 00:44):
also, the type should be integer64 now
Lloyd McKenzie (May 21 2020 at 02:42):
Why primitiveTypes?
Lloyd McKenzie (May 21 2020 at 02:43):
base64Binary, ok, but not any others I think
Grahame Grieve (May 21 2020 at 02:59):
I missed ElementDefinition.maxLength because of where I looked for it
but that's because it's only implemented for uri | oid | uuid | url | canonical | string | dateTime | date | code. All other types are exempt. I don't think that list makes sense. The only ones it doesn't make sense for are boolean | instant | time | uuid
Grahame Grieve (May 21 2020 at 03:00):
but I think that maxSize makes more sense for base64Binary
Lloyd McKenzie (May 21 2020 at 03:37):
length is characters, size is bytes. It's not needed on instant, time or uuid (length is fixed there - so should drop uuid). decimal, integer and specializations are generally limited by things other than # of characters. id length is already constrained - not sure we want/need to allow further limitations? markdown should be in the list if allowing to apply for string isn't sufficient.
Lloyd McKenzie (May 21 2020 at 03:37):
So add markdown to maxLength and rop uuid; add base64Binary to maxSize. Is that about right?
Grahame Grieve (May 21 2020 at 04:24):
integer and specializations are generally limited by things other than # of characters
yes that's true, but not always, so we should do it anyway
Last updated: Apr 12 2022 at 19:14 UTC
