Stream: hapi
Topic: FHIR Spec, HAPI, and semantic versioning
Michael Lawley (Nov 11 2019 at 00:50):
We have StructuredDefinitions from the IG Publisher that are stamped as FHIR 4.0.1, but are being rejected by HAPI (4.0.3) as "Unknown FHIRVersion code '4.0.1'"
Is it unreasonable to expect (at least) patch versions to be forward compatible?
Grahame Grieve (Nov 11 2019 at 00:57):
@James Agnew this is about to an acute pressure point on HAPI. I hope that your imminent release supports 4.0.1. I think I've found and fixed all the points where my code needs to.
Grahame Grieve (Nov 11 2019 at 00:58):
but Michael has a deeper point in mind that I don't know how to solve around the FHIRVersion enumeration
Michael Lawley (Nov 11 2019 at 01:37):
At the moment, 4.1.0-SNAPSHOT (from maven) is rejecting 4.0.1
{ "resourceType": "OperationOutcome", "issue": [ { "severity": "error", "code": "processing", "diagnostics": "Failed to parse request body as JSON resource. Error was: Invalid attribute value \"4.0.1\": Unknown FHIRVersion code '4.0.1'" } ] }
Michael Lawley (Nov 11 2019 at 03:50):
I note that the current (master) dependency from HAPI is <fhir_core_version>4.0.26-SNAPSHOT</fhir_core_version>
and not the latest: <fhir_core_version>4.0.33-SNAPSHOT</fhir_core_version>
Michael Lawley (Nov 11 2019 at 04:05):
Updating to 4.0.33-SNAPSHOT and I now get:
{ "resourceType": "OperationOutcome", "issue": [ { "severity": "error", "code": "processing", "diagnostics": "cvc-enumeration-valid: Value '4.0.1' is not facet-valid with respect to enumeration '[0.01, 0.05, 0.06, 0.11, 0.0.80, 0.0.81, 0.0.82, 0.4.0, 0.5.0, 1.0.0, 1.0.1, 1.0.2, 1.1.0, 1.4.0, 1.6.0, 1.8.0, 3.0.0, 3.0.1, 3.3.0, 3.5.0, 4.0.0]'. It must be a value from the enumeration.", "location": [ "Line[1] Col[26685]", "Line 1, Col 26685" ] }, { "severity": "error", "code": "processing", "diagnostics": "cvc-attribute.3: The value '4.0.1' of attribute 'value' on element 'fhirVersion' is not valid with respect to its type, 'FHIRVersion-list'.", "location": [ "Line[1] Col[26685]", "Line 1, Col 26685" ] } ] }
Grahame Grieve (Nov 11 2019 at 04:21):
this is a schema error
Michael Lawley (Nov 11 2019 at 21:59):
updating hapi-fhir-validation-resources-r4/src/main/resources/org/hl7/fhir/r4/model/schema/fhir-single.xsd
in co junction with changing fhir_core_version
seems to fix this ; not sure if it creates other problems though
James Agnew (Nov 12 2019 at 00:06):
The HAPI 4.1.0 release does support FHIR 4.0.1, confirmed this afternoon- The branch that updates to the latest core structures isn't merged yet, it's likely the last merge before release.
this is a good point about the XSDs though, I did not update them and I should do that.
James Agnew (Nov 12 2019 at 00:07):
And @Michael Lawley no, that shouldn't cause any other issues.
Jim Steel (Nov 12 2019 at 00:08):
Is there also a change to be made to ensure that any subsequent change to 4.0.2 wouldn't break things?
James Agnew (Nov 12 2019 at 00:09):
It's arguable that we shouldn't throw an exception when putting an invalid string into an Enumeration since that's a validation error. Currently though, 4.0.2 would be rejected.
Jim Steel (Nov 12 2019 at 00:09):
Yeah, that doesn't seem like very semantic versioning
Jim Steel (Nov 12 2019 at 00:10):
(if one could be said to be 'very' or 'somewhat' semantic!)
Jim Steel (Nov 12 2019 at 00:12):
I imagine this might be too late for 4.1.0, should I make a github issue for a later release?
Michael Lawley (Nov 12 2019 at 00:48):
@James Agnew Thanks - running the tests throws up a bunch of errors relating to hard-coded expectations of 4.0.0 but also 3.0.1 vs 3.0.2 and the dstu3 XSD
Grahame Grieve (Nov 12 2019 at 02:04):
hmm. I think that there's a wider question than for HAPI about accepting these. it's FHIR that says these are not valid, not HAPI
Jim Steel (Nov 12 2019 at 03:19):
Ah, OK
Last updated: Apr 12 2022 at 19:14 UTC