Coming back to an old topic. Our current JSON/XML schemas reflect the structures in the RM. Now the serialized representations we use at the REST API level are slightly different than the RM JSON/XML representations, so we can’t use the same schemas to validate those.
For instance, POST /ehr returns an EHR in JSON that contains the ehr_status, which is the actual EHR_STATUS serialized to JSON (the last version of the status). In the RM JSON schema, ehr.ehr_status is an OBJECT_REF. So the result of POST /ehr can’t be validated using the JSON schema because of the EHR_STATUS vs. OBJECT_REF mismatch.
@thomas.beale and I talked about this some time ago and he defined some extra types to be used at the Service Model level (openEHR Platform Service Model), which in theory should be the spec in which the REST API spec is based on (but we worked on the SM after the REST API was released).
Now I don’t think we have a formal way of validating API results against a schema, for those results that differ from the RM-based schemas, like when in the RM we have an OBJECT_REF and in REST we have the actual object.
This is an issue for conformance but also for implementation, since a JSON parser instead of parsing an openEHR EHR, should check if it’s a RM valid EHR or an API valid EHR. This is not a huge technical issue, but having a formal way to express API objects and a formal schema for those objects would be a better solution than type checking on the fly to know how to validate and parse a JSON document.
How are implementers dealing with these issues of validating and parsing RM vs. API JSONs/XMLs?