Stream: implementers
Topic: Relative References
Grahame Grieve (Sep 17 2019 at 10:39):
I have a question about a breaking change to a normative part of the specification.
Process note: Breaking changes to normative content are only allowed if everyone agrees that they're a reasonable change to make, and it won't break implementations. This might be one of those cases.
Jens Villadsen (Sep 17 2019 at 10:40):
Grahame Grieve (Sep 17 2019 at 10:40):
https://www.hl7.org/fhir/references.html#literal describes how relative references work. It says that a reference like
Patient/1
is a reference to a resource located at "Patient/1" relative to the resource. There's a special rule that if you accessed the resource by the RESTful API, "relative to" actually means 'Relative to the service base', not to the actual resource.
Grahame Grieve (Sep 17 2019 at 10:41):
Note, however, that this relative reference is also perfectly fine:
old_resources/my_archive/resources/something-else/thisthat.xml
Grahame Grieve (Sep 17 2019 at 10:41):
whatever is served up from this URL must be a resource that is one of the acceptable target types for the element that contains the reference
Grahame Grieve (Sep 17 2019 at 10:44):
There's one thing the specification doesn't say which is kind of surprising to most implementers: there's no rule that a reference like
Patient/1
Actually has to point to a patient. Weird, and I would very strongly recommend against mucking around with people's expectations like that. And if you didn't serve a Patient from a link like that, you probably wouldn't conform to the RESTful API... but maybe you aren't anyway (you don't have to only use resources with the RESTful API).
What this means is that as the reference level, you can't assume that Patient/1 actually references a patient: you have to fetch it to see what it references.
Grahame Grieve (Sep 17 2019 at 10:45):
I think most people would find that surprising... So we could consider changing the specification to say that if a reference is relative, and starts with [Type]/ where Type is one of the known resources, then it SHALL refer to a resource of the named type.
Grahame Grieve (Sep 17 2019 at 10:46):
we can only do that if everyone agrees that this a reasonable rule that no one has deviated from (and we would have to implementer survey on this).
Michele Mottini (Sep 17 2019 at 13:13):
Bulk data relies on all references being in the [Type]/[id] format
Michel Rutten (Sep 17 2019 at 13:41):
I guess a validator would still have to verify by resolving the reference, and report a type mismatch as an error.
Michael Donnelly (Sep 17 2019 at 13:43):
Validators look at a lot of things that normal clients don't need to. ;)
Josh Mandel (Sep 17 2019 at 13:45):
This seems totally good and clear. Out of curiosity: did this come up as a problem in a real-world situation?
Grahame Grieve (Sep 17 2019 at 13:53):
it arose when I was testing a validator fail report (on #hapi if you want to read the details)
Josh Mandel (Sep 17 2019 at 13:54):
Thanks! deep link to the thread.
Jens Villadsen (Sep 17 2019 at 21:27):
This seems totally good and clear. Out of curiosity: did this come up as a problem in a real-world situation?
@Josh Mandel My main focus tends to revolve around real-world situations. Imaginary stuff scares the s**t out of me :scream:
Jens Villadsen (Sep 17 2019 at 21:27):
:grinning_face_with_smiling_eyes:
Jens Villadsen (Sep 18 2019 at 12:54):
Process note: Breaking changes to normative content are only allowed if everyone agrees that they're a reasonable change to make, and it won't break implementations. This might be one of those cases.
@Grahame Grieve How many is everyone and what would the ETA be? Would this go back to eg. STU3?
Grahame Grieve (Sep 18 2019 at 13:04):
well, we would actively seek input repeatedly through all the channels we have, particularly ballot, hammering on the fact that this is a breaking change to normative content that can only stand if no one objects and we have thoroughly asked the community. And if TSC approves that we did all that properly
Grahame Grieve (Sep 18 2019 at 13:06):
and it wouldn't apply retrospectively directly, but it would be pretty strong guidance
Jens Villadsen (Sep 18 2019 at 13:07):
So ... between two days and two years
Last updated: Apr 12 2022 at 19:14 UTC
