search

openEHR / specifications-ITS-REST

openEHR REST API Specifications
https://specifications.openehr.org/releases/ITS-REST/latest
Apache License 2.0
18 stars 15 forks source link

Documentation issue PUT Composition #83

Closed jakesmolka closed 5 years ago

jakesmolka commented 5 years ago

Following #73 the documentation wasn't updated to reflect the changes. See: https://github.com/openEHR/specifications-ITS-REST/blob/74dd2b4755a7d2d7acaadec6f852ef731518d385/src/includes/composition.apib#L76 But simply changing preceding_version_uid in the URL to versioned_object_uid in the URL should fix that, right?

sebastian-iancu commented 5 years ago

thanks @jakesmolka, you are right about this, I will change(fix) this in the upcoming release.

jakesmolka commented 5 years ago

I'm just now realizing that my proposal might not be correct, too.

The snippet

https://github.com/openEHR/specifications-ITS-REST/blob/74dd2b4755a7d2d7acaadec6f852ef731518d385/src/includes/composition.apib#L75

mentions the composition ID in the request body, which by my knowledge would need to be of type version_uid (referencing a specific version, itself). The versioned_object_uid in the URL would be of type, well, versioned_object_uid (referencing the version container). Those would never match.

Or is this how it is supposed to be, i.e. "match" is meant as "the version_uid should be a matching version of that versioned_object_uid in the URL" and not "equals"?

sebastian-iancu commented 5 years ago

The "match" here refers to semantic matching, i.e. the COMPOSITION.uid.value in the body should relate to that of the "owning" versioned_object_uid. It was not about exact version-matching, which is handled by that If-Match={preceding_version_uid} header. I rephrased the text there, hopefully is more clear now.