CODEWITHSUNDEEP
hl7-fhir
DarthGizka
DarthGizka

Reputation: 4675

Ramifications of *not* constraining the URL in conformance resources to a fixed value (fixedUri or system)?

It seems that some conformance resources are written to prescribe fixed URLs (with or without version suffix), for example by constraining meta.profile to a fixedCanonical.

{
    "id": "Invoice.meta.profile",
    "path": "Invoice.meta.profile",
    "fixedCanonical": "http://zrbj.eu/StructureDefinition/foo|1.2.3"
}

This means that users always MUST specify the URL exactly as specified, i.e. with or without version, and the builtin flexibility of the FHIR mechanisms goes down the drain.

If I leave off the constraint then it is the user's choice whether to specify a version or not. Given a profile http://zrbj.eu/StructureDefinition/foo with version 1.2.3 the following four canonicals all work as expected in meta.profile of resource instances:

http://zrbj.eu/StructureDefinition/foo
http://zrbj.eu/StructureDefinition/foo|1.2
http://zrbj.eu/StructureDefinition/foo|1.2.2
http://zrbj.eu/StructureDefinition/foo|1.2.3
http://zrbj.eu/StructureDefinition/foo|1.2.4

The fifth example (resource with higher patch level than the profile) may be slightly counter-intuitive but that is how semantic versioning (SemVer) is supposed to function here: if major and minor version correspond then a resource with lower patch level must be accepted by a profile version with higher patch level and vice versa (i.e. compatibility goes both ways).

The following canonicals do not match major.minor of the profile and are rejected, as expected:

http://zrbj.eu/StructureDefinition/foo|1
http://zrbj.eu/StructureDefinition/foo|1.1
http://zrbj.eu/StructureDefinition/foo|1.3

Our usage scenario calls for the second accepted case: resources must 'commit' to one of the structural versions (major.minor) defined as permissible on the day of their creation, and they must document this by specifying the chosen version in the URL suffix. This still leaves the profile author free to fix minor things and increment the patch level, as long as two-way compatibility is preserved. It also offers a way of fixing certain classes of bugs with the least amount of collateral damage.

Is there anything that speaks against leaving off the URL-fixing constraint, given a usage scenario as the one I described?

UPDATE

Lloyd McKenzie has pointed out that extension URLs cannot be versioned. Hence I have rewritten the examples to use meta.profile instead.

Upvotes: 0

Views: 67

Answers (1)

Lloyd McKenzie
Lloyd McKenzie

Reputation: 6793

Extension.url is defined as having a type of "uri", not "canonical". That means that version-specific references are not permitted. The version of the extension "in play" is driven by the version of the core specification in play and/or the versions of the IGs declared in the CapabilityStatement of the server. If neither of these define the extension, then the version of the extension may be ambiguous. For this reason, its important to not significantly change the semantics of an extension over time - instead, if needed, define a new extension.

There is currently no conformant mechanism of declaring the 'version' of an extension in an instance. If this is an essential requirement for you, submit a change request using the "propose a change" link at the bottom of any page in the spec and the community can discuss alternatives. (Given that Extension is now normative, it is extremely unlikely that changing to allow the 'canonical' syntax will be the agreed solution, as that would be a breaking change.)

Upvotes: 1

Related Questions