Uploaded image for project: 'FHIR Specification Feedback'
  1. FHIR Specification Feedback
  2. FHIR-44093

Remove guidance to construct canonical URL using resource name

XMLWordPrintableJSON

    • Icon: Change Request Change Request
    • Resolution: Persuasive with Modification
    • Icon: Medium Medium
    • Canonical Resource Management Infrastructure (FHIR)
    • 1.0.0-ballot2
    • Clinical Decision Support
    • Naming Conventions [deprecated]
    • 3.1.1.1
    • Hide

      Agreed, with the caveat that for Libraries, conformance requires the use of Name because that's how libraries are resolved in CQL. Update the language to:

      1) Recommend the convention use the "id", but note that this is the "original id as established at authoring time, and not expected to be permanent when the artifact appears in other contexts"
      2) Note that for CQL Libraries in particular, the "original id" must match the name of the CQL library

      Show
      Agreed, with the caveat that for Libraries, conformance requires the use of Name because that's how libraries are resolved in CQL. Update the language to: 1) Recommend the convention use the "id", but note that this is the "original id as established at authoring time, and not expected to be permanent when the artifact appears in other contexts" 2) Note that for CQL Libraries in particular, the "original id" must match the name of the CQL library
    • Paul Denning/Jen Seeman: 14-0-1
    • Correction
    • Non-substantive

      The guidance for constructing the canonical URL indicates that the resource name SHOULD be used instead of the id. It concedes that this is not typical, but suggests it is necessary since the id may change when the artifact is hosted in different environments.

      I think the fact that the id may change during exchange is irrelevant, because the canonical never changes (even if the id does). Since the canonical is constructed at design-time, it reflects the original id – not the id after it has been exchanged.

      IMO, it is better to either follow the established convention (SHOULD be constructed as {_}

      {package-canonical-base}

      /{resource.resourceType}/{resource.id}{_}) or to not provide any guidance at all (which is only a little different since the SHOULD strength already requires consuming systems to expect anything). Recommending an approach that goes against convention seems to provide little value.

       

            jen_seeman Jennifer Seeman
            cmoesel Chris Moesel
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: