Stream: implementers
Topic: Different versions in and out for operations
Lloyd McKenzie (Oct 28 2019 at 19:33):
GF#20912 notes that we currently say that it's an error to have an interaction that supports multiple versions - i.e. the Content-Type and Accept headers aren't for the same version. However, we have a $convert operation that does exactly that. We're wondering whether we should just carve out an exception for that one operation or whether it's appropriate to loosen the rule to allow version mixing in other situations. If we loosen the rule, we'd also need to define how we wanted to enforce constraints so version mixing only occurs in appropriate circumstances and in appropriate ways
Grahame Grieve (Oct 28 2019 at 22:22):
yes
Lloyd McKenzie (Oct 29 2019 at 03:21):
That's an interesting answer to an either/or question @Grahame Grieve :)
Grahame Grieve (Oct 29 2019 at 03:23):
yep
Christiaan Knaap (Oct 29 2019 at 09:35):
I can also imagine $transform uses with different fhirVersions (use this R4 StructureMap to map the input to an R3 Resource).
For all the normal http interactions I don't really see a use for it, nor for any of the other operations defined in the spec.
So I would suggest that all http interactions and predefined operations SHOULD have the same fhirVersion on Content-Type and Accept, except for $convert and $transform. Besided that, custom operations MAY accept different fhirVersions on Content-Type and Accept.
But that leaves the question on how an operation can define that it accepts different versions.
David Pyke (Oct 29 2019 at 12:14):
In my limited opinion, you should be loosening the rule in either case. You either loosen it so that only $convert can function (and any that follow it's strict interaction rules) or further if there are other operations that might benefit it. I don't think starting a potential list of exemptions would be a good way forward
John Moehrke (Oct 29 2019 at 12:35):
The core specification should not speak about deployment issues. It is a core spec. An implementation guide certainly can speak of deployment issues. Thus the core spec should not state that it is an error to have an interaction with multiple versions. It should have a well-defined error to indicate this condition, but it should not mandate any specific condition. It could use an example that is the one we describe today.
Grahame Grieve (Oct 29 2019 at 19:31):
I don't see that this is a deployment issue. It's a fundamental issue of definition of the API - when can you mix versions on a call
Last updated: Apr 12 2022 at 19:14 UTC
