Stream: Touchstone
Topic: Unrecognised property '@resourceType'
Abbie Watson (Mar 30 2017 at 18:26):
Another Touchstone question... this time regarding "ERROR: Unrecognized property @resourceType', as you can see here:
Screen-Shot-2017-03-30-at-1.16.46-PM.png
Abbie Watson (Mar 30 2017 at 18:28):
I know *why* this is erroring. It's because we're including the resourceType field in our response, like so:
Screen-Shot-2017-03-30-at-1.19.35-PM.png
Abbie Watson (Mar 30 2017 at 18:29):
But why is this incorrect? I don't understand why having the resourceType is invalid. It's semantically richer; and consistent with the FHIR spec, and more effort to remove.
Richard Ettema (Mar 30 2017 at 23:50):
Validation of the operation payloads (request and response) is defined via the assert.validateProfileId. Touchstone leverages the FHIR Java RI Validation Engine (for each corresponding FHIR version) to support this assert directive. So, the error message you see (in red) is coming from the FHIR Validation Engine. When validating a JSON formatted resource, the validation rules follow the FHIR specification for the JSON format found here - http://hl7.org/fhir/STU3/json.html. If you examine the "Comparison with XML" section - http://hl7.org/fhir/STU3/json.html#xml - you'll see that the resourceType is a special property that is used only once within the JSON representation of the resource instance.
Richard Ettema (Mar 30 2017 at 23:52):
So, I'm afraid your use of the resourceType property outside of this context is invalid in the current definition of the spec.
Abbie Watson (Mar 31 2017 at 00:13):
I don't see anything in either of those links about resourceType only being allowed to be used once in an object. And who would come up with such a rule? Particularly if we're globbing resources into each other.
I understand that the FHIR Java RI Validation Engine may be configured so it rejects resourceTypes in sub-objects; but it seems overly restrictive. It's simply enforcing an unneeded boxing/unboxing problem. In the real world, data modeling is going to happen with the minimal amount of data transformations possible, and people are going to want to simply glob resource onto others.
Richard Ettema (Mar 31 2017 at 00:38):
True. resourceType is not explicitly restricted in the descriptions on that page. However, it is restricted based on the individual resource type definitions based each type's defined structure; i.e. resourceType is not a defined property in the resource's structure anywhere except as defined on the JSON format page as described in the "Comparison with XML" section.
The main issue here is the ability of any FHIR system to render the resource in any of the supported formats: XML, JSON and RDF (turtle). Rendering your version of the Organization resource from JSON into XML would produce an invalid XML format according to the FHIR structure (or more appropriately, the FHIR profile/StructureDefinition).
Richard Ettema (Mar 31 2017 at 00:46):
Ultimately, it comes down to interoperability. Insuring the content of the resources is consistent across all format types insures that FHIR systems can reliably exchange those resources.
Last updated: Apr 12 2022 at 19:14 UTC
