Stream: implementers
Topic: FHIR MIME/Media Types
Bryn Rhodes (Jun 15 2016 at 20:26):
In the past few connectathons, I've consistently run in to issues with the FHIR MIME type as it's described in the specification (application/xml+fhir or application/json+fhir):
https://hl7-fhir.github.io/http.html#mime-type
The problem is that some RESTful frameworks (e.g. RESTEasy) have trouble dealing with the content type, and I believe that the reason for the problem is that the media types are not consistent with the current best practice for media types. At least, that's my reading of this RFC:
http://tools.ietf.org/html/rfc6838
In addition, a quick review of the media type registry here:
http://www.iana.org/assignments/media-types/media-types.xhtml
seems to support that interpretation because there are no media types registered that use the xml+XXXX or json+XXXX format.
So I think this raises two questions:
1) Should the FHIR spec be changed to specify the media types as application/fhir+xml and application/fhir+json
2) Should these media types be registered with IANA?
Andy Stechishin (Jun 15 2016 at 20:38):
See FHIR list server for response (or ITS list)
Grahame Grieve (Jun 16 2016 at 00:28):
Implementers need to express their opinion on this one please - here or on the list
Stephen Royce (Jun 16 2016 at 00:36):
We haven't hit this (yet!), but I would think that using the standard XML and JSON MIME types would be better. I'm very unclear on what practical advantage you'd get from using FHIR-specific ones.
Grahame Grieve (Jun 16 2016 at 01:15):
pretty much the only identified advantage is not changing existing practice
Erich Schulz (Jun 16 2016 at 01:24):
+1 for using standard mime types - the joy of having your tools detect the data and handle it nicely for you seem to outweigh the need know you have a FHIR resource (which is determinable from deeper inspection of content, no?)
Michael Lawley (Jun 16 2016 at 01:25):
I strongly support the change
Brian Postlethwaite (Jun 16 2016 at 01:32):
Without the fhir being included in the mimetype (somewhere) from a platform perspective there is no way that you can choose an app to load a document format (association).
Should we also request a file extension while we go through the stress?
Brian Postlethwaite (Jun 16 2016 at 01:32):
(Not that anyone is doing this at the moment anyway)
Grahame Grieve (Jun 16 2016 at 01:33):
fhir will be included in the mime type. Erich is wrong about that
Erich Schulz (Jun 16 2016 at 01:34):
?
Grahame Grieve (Jun 16 2016 at 01:35):
application/fhir+xml, application/fhir+json, application/fhir+ttl
Grahame Grieve (Jun 16 2016 at 01:35):
those are the new proposed types. Not sure about the validity of the last one. @Eric Prud'hommeaux can you comment on our best choice for turtle mime type please
Grahame Grieve (Jun 16 2016 at 01:36):
I don't think we want an extension registered
Brian Postlethwaite (Jun 16 2016 at 01:37):
Thanks, just wanted to ensure that everyone was on the same page.
And *not* just using application/xml
Erich Schulz (Jun 16 2016 at 01:38):
oh right - sorry for confusion
Abbie Watson (Jun 16 2016 at 02:02):
Register the fhir-* mime-types with IANA, but make them optional and for explicit opt-in scenarios. They will enable a lot of great functionality, similar to the /metadata conformance statements.
Grahame Grieve (Jun 16 2016 at 02:17):
I don't know what this means 'make them optional and for explicit opt-in scenarios'
Stephen Royce (Jun 16 2016 at 02:22):
I'd really like to just be able to use application/xml or text/xml. I think I understand what @Brian Postlethwaite's saying, but do we have to force everyone to do that?
Stephen Royce (Jun 16 2016 at 02:23):
I also agree with @Abigail Watson that the extensions should be registered with IANA, especially if you always have to use them.
Andy Stechishin (Jun 16 2016 at 02:25):
The previous version could not be registered IANA because they did not follow the specified format, if the decision was to move to the standard format ITS could then proceed with IANA registration just like we did for CDA and others
Stephen Royce (Jun 16 2016 at 02:26):
Abbie Watson (Jun 16 2016 at 02:27):
So, like, after registering them, don't require that they be used. Let people opt-in at their own pace.
Grahame Grieve (Jun 16 2016 at 02:28):
I think that changing the spec to say that you don't have to use specific mime types would be a huge step backwards. really big
Stephen Royce (Jun 16 2016 at 02:29):
Works for me.
Grahame Grieve (Jun 16 2016 at 02:29):
and I don't know why just using application.xml would be good for anyone
Abbie Watson (Jun 16 2016 at 02:29):
That's not what I'm saying. I'm saying stick with application/json and application/xml in the standard. And application/fhir-json and application/fhir-xml are nice-to-haves. But do register them.
Stephen Royce (Jun 16 2016 at 02:30):
It's easy. You don't have to think about. So when you're in you're initial stages of development everything still works and you can address the MIME type later.
Grahame Grieve (Jun 16 2016 at 02:30):
you mean, stick with pplication/json+fhir and application/xml+fhir in the standard. And then create chaos by letting people use either
Grahame Grieve (Jun 16 2016 at 02:31):
I don't understand why you don't use the correct mime types, Stephen
Stephen Royce (Jun 16 2016 at 02:32):
Becuase the toolset I use gives me application/xml for free. I have to take explicit action if I want to be more precise about the flavour of XML.
Grahame Grieve (Jun 16 2016 at 02:34):
you already had to take that action, yes? and why would we force everyone to accept the mime type application/xml as well as the proper one in order to save you some work? that doesn't make sense. As well as potentially breaking existing applications that are free to use application/xml for their own use now
Stephen Royce (Jun 16 2016 at 02:38):
There's a change required anyway, by the sound of things, so for those who've actually implemented the badly defined types (which it would seem is not everyone), just include the more general types when the change is made. (I haven't had to take any action. The whole toolset is XML-based and assumes application/xml unless you take individual action on every transaction to do otherwise.)
Grahame Grieve (Jun 16 2016 at 02:39):
there's a big difference between changing from one fixed type to another, to changing from one fixed type to a set of types that have variable meaning. I'm really fiercely opposed to a change like that
Stephen Royce (Jun 16 2016 at 02:39):
I'm not that fussed myself, because I would get around to doing it properly at some point anyway, but it seems that I'm not the only one who's using application/xml and the like.
Stephen Royce (Jun 16 2016 at 02:39):
How do they have "variable meaning"?
Grahame Grieve (Jun 16 2016 at 02:40):
application/xml has a very distinct meaning from application/xml+fhir or application/fhir+xml
Stephen Royce (Jun 16 2016 at 02:41):
application/xml means XML and inspection of the content verifies that it's FHIR. I know all I need to know (Brian's point aside, that is).
Grahame Grieve (Jun 16 2016 at 02:41):
not so. You're only considering one use. There's other uses where there's no instance on which to decide. And then there's conformance questions - the instance isn't FHIR - is that a non-conformance or not?
Stephen Royce (Jun 16 2016 at 02:43):
Re conformance: for me, it's non-conformance. When wouldn't it be?
Stephen Royce (Jun 16 2016 at 02:43):
Re no instance: not sure what you're talking about?
Stephen Royce (Jun 16 2016 at 02:46):
Further re conformance: I'm a FHIR server; if you don't send me FHIR data, you're not playing by the rules regardless of what the MIME type says.
Grahame Grieve (Jun 16 2016 at 02:48):
again, not so simple, I'm afraid. And you request content by mime type. And specify it by mime type. But servers have here-to-fore been able to use application/xml for something other than FHIR. You're proposing to remove that. and I don't see any benefit except to save some people from doing some thing in their server stack
Stephen Royce (Jun 16 2016 at 02:53):
If I request application/xml data from a FHIR server, what data would I expect to get? I can still use application/xml for other data, just not from my FHIR server. (This assumes, which I do, that the FHIR server resides at an explicit URL that is all it's own. I'm not sure why you'd design your server stack otherwise, but if that has to be catered for then that implementation would be a bit buggered. 
)
Grahame Grieve (Jun 16 2016 at 02:54):
right now you are *likely* to get fhir xml. you do from mine. But that's not behviour that's described in the spec, and you might get a different kind of data from some other server. that would be allowed behaviour
Grahame Grieve (Jun 16 2016 at 02:55):
any xml response - odata, dicom xml, CDA, anything. It's all application/xml. And there are servers doing this sort of stuff now
Stephen Royce (Jun 16 2016 at 03:00):
I would think though that it would not be unreasonable for the FHIR specification to disallow returning non-FHIR data from a FHIR server. DICOM, CDA, &c., would have to wrapped in a FHIR package of some sort, not native. But maybe that's too much. I'd be surprised though if at least some of those servers providing the other data types are not using application/xml to describe it anyway. So they should already know how to deal with the problem.
Stephen Royce (Jun 16 2016 at 03:01):
But, as I said, I'm not that fussed about it. The intention is that we'd use the fully-specified MIME types eventually, so if that's sooner rather than later, it won't make that much difference to us.
Stephen Royce (Jun 16 2016 at 03:02):
Providing, of course, that we're talking compliant, registered MIME types!
James Butler (Jun 16 2016 at 03:03):
This very thing came up in discussions about serving Observation attachments - I think my colleague Rowan asked about it here. Check out http://hl7.org/fhir/binary.html#rest for an example of the spec talking explicitly about different content types.
Grahame Grieve (Jun 16 2016 at 03:04):
ah yes that's one place changing to allow application/xml is explicitly nasty
Stephen Royce (Jun 16 2016 at 03:10):
I'm not sure why it's "nasty", but would you have to include application/(xml|json) in the list of MIME types alongside the FHIR-specific ones, i.e. the general types still mean "give me FHIR data;" which is what they should from a FHIR server.
Stephen Royce (Jun 16 2016 at 03:14):
Although, I suppose, if the content of your binary resource is already application\xml you could argue that you should serve it up as is. But then, that could be an explicit exception to the exception! 
Stephen Royce (Jun 16 2016 at 03:15):
Given that it's a binary resource, the requester would have to deal with their own lack of specificity in the read request.
Keith Boone (Jun 16 2016 at 06:24):
I'm in favor of doing the right thing. Servers should be nice to people though, and do what they mean when they ask for it the old way, or if they can figure out what the user meant. Apply Postel's principle here.
Peter Scholz (Jun 16 2016 at 08:10):
I do strongly support using the standard mime type encodings (application/fhir+XXXX) and registering these mime types @IANA
As a server I would gracefully accept application/xml, application/json as shortcuts to the corresponding application/fhir+XXXX mime types but would use the "official" mime type specification on the response.
Jenni Syed (Jun 16 2016 at 16:15):
+1 to using the IANA standard and registering new mime types.
The Binary resource is the only place our server wouldn't automatically translate the generic json request to a fhir json request because of how that resource works.
Jenni Syed (Jun 16 2016 at 16:15):
At least he only place as of now that we wouldn't automatically translate
Josh Mandel (Jun 16 2016 at 16:30):
I'm totally on board with this too (dirty secret of our current SMART sever is it just looks for the substring "json" anywhere in the accept header :-)
Todd Cooper (Jun 16 2016 at 18:12):
Postel at work ...
Richard Ettema (Jun 16 2016 at 18:40):
+1 for IANA standard compliance. This would be a minor code change for my client and server. Same as @Peter Scholz I gracefully accept application/xml and application/json, and respond with the official FHIR mime-types.
Grahame Grieve (Jun 16 2016 at 20:40):
well, so far we haev strong endorsement of this idea in across all the forums
Grahame Grieve (Jun 16 2016 at 20:41):
so, GF#10199
Grahame Grieve (Jun 16 2016 at 20:47):
and also GF#10200
Stephen Royce (Jun 17 2016 at 01:03):
Peter Jordan (Jun 17 2016 at 05:33):
When doing this it might be useful to add a table to the specification with columns for Request Accept Header, Request _format parameter and preferred Response Content Type and rows for each combination of the Request MIME Types application/xml, application/fhir+xml, application/json & application/fhir+json. I don't find the 'overrides' advice in the current section on Content Types & Encodings particularly clear.
Grahame Grieve (Jun 17 2016 at 06:51):
what is 'preferred Response Content Type '?
Peter Jordan (Jun 17 2016 at 07:00):
What, according to the FHIR specification, the Server should return in the Response Content Type header - given what the client has placed in the Request Accept Header and/or the Request _format parameter.
Grahame Grieve (Jun 17 2016 at 07:01):
ah ok
Last updated: Apr 12 2022 at 19:14 UTC
