Stream: fmg
Topic: breaking or not?
John Moehrke (Oct 08 2018 at 12:35):
The Observation discussion around valueAttachment has been characterized as 'okay to defer' because we can always add an element after a Resource goes normative. I like this approach, lets us think and change. However this is adding a variation of value[x], and I think that is a breaking change. Imaging if we do add valueAttachment in the future, an Observation resource that uses valueAttachment, will look like an invalid resource to an old system, as it is missing a value[x]. Meaning the first normative Observation without a valueAttachment is not future proof to adding other flavors of value[x]... or did we cover this? If so, how?
Grahame Grieve (Oct 08 2018 at 12:35):
technically, we commit to forward compatibility
Grahame Grieve (Oct 08 2018 at 12:36):
see http://build.fhir.org/versions.html
John Moehrke (Oct 08 2018 at 14:23):
I understand that, and re-read just to be sure. The issue I think I am pointing out is a forward compatibility problem. Caused by the proposal to add the new element, not as just a optional element, but to add it to value[x]. Thus added to value[x] it becomes an issue, because value[x] effectively must be populated OR the data absent reason must be populated. It would be wrong to indicate a dataAbsentReason, as you have populated valueAttachment. Thus this is similar to adding a new mandatory element to a normative resource. Right? Unless somehow we indicate in the backward compatibility a new recommendation to "[x]" elements are allowed to add new datatypes?
Lloyd McKenzie (Oct 08 2018 at 15:20):
Sigh.
We haven't talked about impact of variants. However, my reading is that this is still an allowed change. Old instances are valid in new systems. New instances aren't necessarily valid in old systems.
Last updated: Apr 12 2022 at 19:14 UTC
