Stream: implementers
Topic: Canonicals within references
Elliot Silver (Nov 18 2021 at 23:34):
The resource resolution scheme described at http://build.fhir.org/references.html#literal, indicates that Reference.reference can contain a canonical, and that canonicals are part of the reference resolution scheme. Is this intended, or is it an accidental leftover from before we cleaved off canonical from Reference?
Josh Mandel (Nov 19 2021 at 00:08):
Hmmm. I don't know the intention, but canonical URLs are valid absolute URIs which makes them valid Reference.references. Should there be an explicit statement that it's okay to resolve them from a cache of canonical content rather than dereferencing them over http? I kinda think it's a fair approach whether or not we specify it.
Elliot Silver (Nov 19 2021 at 00:12):
I think we do say you can get them from a cache: "The URL may contain a reference to a canonical URL (see below) and applications can use the canonical URL resolution methods they support..."
Elliot Silver (Nov 19 2021 at 00:14):
I'm just surprised to see us allow canonical resolution in Reference when we have a whole other data type specifically for canonicals.
Josh Mandel (Nov 19 2021 at 02:44):
The other data type is great for reference that _need to be canonical_. I'm not sure that's an argument against allowing references that might or might not be canonical to be canonical.
Elliot Silver (Nov 19 2021 at 03:01):
OK. It isn't that big an issue to me, I just saw it and thought it might have accidentally slipped through in. And I realize at this point even if we wanted to remove that ability, it would probably be pretty hard to do. (I've got other breaking changes I'd rather fight.)
Josh Mandel (Nov 19 2021 at 03:52):
it might have accidentally slipped through
I agree @Elliot Silver -- I have no idea whether this is intentional. Bet @Lloyd McKenzie will tell us when he has a chance. I'm just saying I happen to like it (but can understand why others might not).
Lloyd McKenzie (Nov 19 2021 at 04:03):
I'm pretty sure I never wrote that text. @Grahame Grieve?
Josh Mandel (Nov 19 2021 at 04:08):
OK, so https://github.com/HL7/fhir/commit/13e9c9f10ce30f7a0c47c07652f32ece4bfd46b8 -- based on FHIR-16865. Definitely intentional, explicit, and came after the canonical datatype was introduced.
Josh Mandel (Nov 19 2021 at 04:09):
(I used git blame on references.html)
Grahame Grieve (Nov 19 2021 at 04:13):
yes I thought I wrote it. The question that lead to that was 'can Any contain a reference to a canonical resource?" and the answer must be yes
Lloyd McKenzie (Nov 19 2021 at 04:18):
But you can only specify the canonical resource in the reference if it's an actual valid reference, not if it's a canonical that doesn't resolve to a FHIR server, correct?
Josh Mandel (Nov 19 2021 at 04:29):
should only. Not sure about "can".
Lloyd McKenzie (Nov 19 2021 at 04:34):
It makes a huge difference to code. I mean, sure, you can include a URL that won't resolve and fail to resolve it. If if you can have a reference to a canonical and you're expect to do a canonical-like search to find it rather than just hitting the URL and bringing back whatever's there, that's a pretty significant imposition on Reference.
Josh Mandel (Nov 19 2021 at 14:03):
Sure, but the same argument can be applied for almost any content that is sitting at a URL and resolvable only if you have the right security in place, where that could be plenty of interesting and arbitrary security approaches that have their own flavors of authentication and authorization, all of which also requires writing specific code. We certainly don't prohibit that.
Elliot Silver (Nov 19 2021 at 17:31):
Grahame Grieve said:
The question that lead to that was 'can Any contain a reference to a canonical resource?" and the answer must be yes
Absolutely, a reference can contain a reference to a ValueSet, CodeSystem, StructureDefinition or any other canonical resource. That reference can also use the canonical URL for that resource, if the canonical URL resolves to a resource using the FHIR resource resolution rules. So yes, Any can contain a reference to a canonical resource, but that doesn't mean it needs to be a canonical reference. What is the use case for supporting this?
I agree with @Lloyd McKenzie . Adding this complexity to reference seems like a significant imposition.
Lloyd McKenzie (Nov 19 2021 at 18:31):
If you have a Reference, the expectation (as I understood it) was that the sole way to resolve it is executing a GET on that URL to retrieve the content. There was never any expectation that you might search through all of the registries you knew for a resource where url=[Reference.reference.value]. I'm fine with references that don't resolve in some circumatances. I'm not fine with adding an additional mechanism to go find them or references that aren't required to follow FHIR's rules for RESTful URLs.
Josh Mandel (Nov 19 2021 at 18:34):
We're not adding anything; we're discussing something that we added (or explicitly documented as allowed) in 2018.
Lloyd McKenzie (Nov 19 2021 at 18:48):
Yeah, that tracker item is pretty clear. I just don't think the vast majority of the world knows and understands that's an expectation.
Vassil Peytchev (Nov 19 2021 at 19:02):
Is there a "master list" of HL7-defined canonicals?
Grahame Grieve (Nov 21 2021 at 10:53):
well, in the base spec, yes: https://hl7.org/fhir/ns.html
Grahame Grieve (Nov 21 2021 at 10:53):
there's no master list that covers all the IGs too
Grahame Grieve (Nov 21 2021 at 10:54):
I think it's true to say that we have no language that prevents a system from doing canonical-type resolution on a reference, but we we have no language that suggests that systems should do that, or should be capable of it
Josh Mandel (Nov 21 2021 at 14:40):
"applications can use the canonical URL resolution methods they support" is a lot more than "no language that prevents". It's an explicit affirmation of this practice.
Grahame Grieve (Nov 22 2021 at 08:40):
that was Lloyd's wording not what the spec says
Last updated: Apr 12 2022 at 19:14 UTC
