Binary instead of binary - N-Infra #25

XMLWordPrintableJSON

    • Type: Change Request
    • Resolution: Persuasive
    • Priority: Medium
    • FHIR Core (FHIR)
    • STU3
    • FHIR Infrastructure
    • Binary
    • 2.35.3.3
    • Hide

      Change the text as follow (changes highlighted with bold font)

      When a read request is made with a FHIR type in the Accept header (e.g. "application/fhir+xml" or "application/fhir+json") the *B*inary resource is returned in the requested FHIR format. This applies even when the binary data itself has a FHIR mime type

      The *B*inary resource is always represented in the native FHIR format when wrapped in a Bundle

      (...)

      When binary data is written to the server (create/[update|http://hl7.org/fhir/2018Sep/http.html#update] - POST or PUT), the data is accepted as is and treated as the binary content of a Binary, including when the content type is "application/fhir+xml" or "application/fhir+json", except for the special case where the content is actually a Binary resource.

      Note that when client requests a *B*inary resource using a generic mime type (application/xml, text/xml, or application/json), the server SHOULD return the content directly if the content-type format matches the requested mime type (e.g. if the Accept header is application/json, and the contentType is vnd.xacml+json). However, servers might not always be able to interpret mime types correctly, and clients SHOULD be prepared to receive either format.

      Show
      Change the text as follow (changes highlighted with bold font) When a read request is made with a FHIR type in the Accept header (e.g. "application/fhir+xml" or "application/fhir+json") the *B*inary resource is returned in the requested FHIR format. This applies even when the binary data itself has a FHIR mime type The *B*inary resource is always represented in the native FHIR format when wrapped in a Bundle (...) When binary data is written to the server ( create /[update|http://hl7.org/fhir/2018Sep/http.html#update] - POST or PUT), the data is accepted as is and treated as the binary content of a Binary, including when the content type is "application/fhir+xml" or "application/fhir+json", except for the special case where the content is actually a Binary resource. Note that when client requests a *B*inary resource using a generic mime type (application/xml, text/xml, or application/json), the server SHOULD return the content directly if the content-type format matches the requested mime type (e.g. if the Accept header is application/json, and the contentType is vnd.xacml+json). However, servers might not always be able to interpret mime types correctly, and clients SHOULD be prepared to receive either format.
    • Rick Geimer/Bryn Rhodes: 7-0-0
    • Clarification
    • Compatible, substantive
    • STU3

      Existing Wording: e.g., "...the binary resource is returned in the requested FHIR format."

      Comment:

      I presume "binary resource" actually means the resource that is defined as Binary (in other words this resource)? Which is to say that it would be clearer if "Binary resource" were used as opposed to "binary resource". It's a matter of overloading terms--binary resource could actually mean the value of Binary.data.

      Though, the 6th bullet indicates that "...the data is accepted as is and treated as the binary content of a Binary...", which tells me that the use of 'binary resource' was intentional.

      Which is to say that the discussion is confusing due to the overloaded use of the word 'binary'.

      A visual representation of the possible workflows would be useful.

      Summary:

      Binary instead of binary

            Assignee:
            Unassigned
            Reporter:
            euvitudo
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: