An endpoint for resolving EHR-URIs + changed Query URI about specifications-its-rest HOT 2 OPEN

Well, up to the point of the composition/folder root based on just object/verision EHR-URIs will be valid as is now. But the continuation beyond that including square brackets etc likely needs this additionl approach.

In some use-cases (e.g. where you want to retrieve the full composition but highlight a certain part) you could theoretically use the composition resource instead and replace the slash (after versionid) with a # and hope that a clever client can navigate to the highlight (and that things get url-encoded or tolerated by the server/browser... Example: /ehrs/{ehrId}/compositions/56d03821-8e89-cca769b7d39e::test2.eee.mi.imt.liu.se::1#content[openEHR-EHR-SECTION.vital_signs.v1]/items[openEHR-EHR-OBSERVATION.blood_pressure.v1]/data/

...but the /query/path resource-suggestion above primarily caters for another use-case where you just want to retrieve a piece of a composition pointed out by the EHR-URI. See table 1 in the LiU-EEE-paper where both use-cases are listed (but using different old syntax)

from specifications-its-rest.

Just a dumb Q: I assume the idea is that a dedicated end-point provides a place where translations of EHR_URIs as they are now into proper EHR REST calls and paths? I.e. we remove any assumption that a raw EHR-URI needs to be a valid REST path in the APIs we are now developing?

from specifications-its-rest.