Stream: conformance
Topic: References between parameters
Simone Heckmann (Mar 23 2022 at 08:46):
I was wondering: Is there any convention of how resources in Parameters (in- or output of an operation) can reference each other?
Since we don't have a mechanism like the fullUrl in a Bundle...
Simone Heckmann (Mar 23 2022 at 08:56):
I found the following in the description of the Parameters resource:
Internal References When internal references are resolved in a resource in a parameter.resource, the resolution stops at parameter.resource. This allows resources to appear more than once in a Parameters resource, and also means that resources cannot reference content in another resource using an internal reference (except for references inside contained resources)
References When resolving references in resources, the applicable Operation Definition may specify how references may be resolved between parameters. If a reference cannot be resolved between the parameters, the application should fall back to it's general resource resolution methods
Can anyone explain the difference between "internal References" and "References" in this context?
Simone Heckmann (Mar 23 2022 at 08:57):
Does internal mean contained references, like #<id>? But their resolution always stops at the root of the Resource, no?
Josh Mandel (Mar 23 2022 at 14:29):
(deleted)
Josh Mandel (Mar 23 2022 at 14:29):
(deleted)
Josh Mandel (Mar 23 2022 at 14:35):
https://build.fhir.org/references-definitions.html#Reference.reference mentions internal fragment references, and the short description of this same element mentions " internal references". From https://build.fhir.org/references.html almost every mention of internal references seems to be dealing with reference that include # fragment suffixes.
Josh Mandel (Mar 23 2022 at 14:39):
Under this interpretation, the phrase:
This allows a resource to appear more than once in a parameters resource
Is basically saying that redundant content (e.g. two resources each including the same id and meta.versionId) can be included at different places within a Parameters.descendants().resource tree.
Josh Mandel (Mar 23 2022 at 14:41):
You have to work but none of this is really clear to me, and without examples the languages cited above Simone is unlikely to lead to consistent implantations.
I think we ought to have a built-in default semantics for resolving references within Parameters -- or maybe a couple of different resolution methods that and operation definition can choose from .. but we should not force every mplementation guide to have define their own from scratch.
Simone Heckmann (Mar 23 2022 at 15:16):
That would indeed be very helpful!
Lloyd McKenzie (Mar 23 2022 at 16:28):
I asked for something formal and "define it in your IG" was the outcome of the discussion.
Simone Heckmann (Mar 31 2022 at 15:11):
I'd much rather have something formal that is considered "best practice" with the option to "define it in your IG" if you don't like it :wink:
Simone Heckmann (Mar 31 2022 at 15:32):
I am currently trying to "define it in my IG" and I am quite uncertain about what "best practice" could be here.
My idea would be to preferably use UUIDs with the referencing resource having reference="urn:uuid:<uuid> and the target resource having id="<uuid>"
Next best thing would be relative URLs with the referencing Resource havingreference="<Resourcetype>/<id>" and the target resource having id="<id>"
Should absolute URLs be allowed too?
Would it make sense to instead just generalize that "the id part" of the reference should match the id of the target and make no assumptions about the kind of URI thats used?
Do we have a common definition of what "the id part" of an URI is, considering the different shape and form of URLs and UUIDs?
Would it be simpler to allow only URLs since the id part could easily be populated with a UUID if the Client wants to assign temporary ids?
Lloyd McKenzie (Mar 31 2022 at 15:46):
What I've done is use relative references and indicated that the references are resolved within the context of the Parameters instance. (Because I find UUIDs to be a pain.)
Simone Heckmann (Apr 01 2022 at 14:02):
I agree. The only argument I could make for UUIDs is that there is better alignment between Transaction and Operation.
Last updated: Apr 12 2022 at 19:14 UTC
