Stream: implementers
Topic: XML Serialisation
Richard Kavanagh (Apr 18 2016 at 16:40):
We have a new team member that is looking at the XML serialisation used in FHIR.
We have a question as to why XML serialises primitive values in to attributes
Richard Kavanagh (Apr 18 2016 at 16:41):
So why does FHIR do this
<name>
<use value="usual"/>
<given value="Jim"/>
</name>
Richard Kavanagh (Apr 18 2016 at 16:41):
Instead of this
Richard Kavanagh (Apr 18 2016 at 16:42):
<name>
<use>usual</use>
<given>Jim</given>
</name>
Richard Kavanagh (Apr 18 2016 at 16:42):
I know there is a rationale for this and this has been debated extensively in the history of FHIR. I'm struggling to find those reasons documented though.
Richard Kavanagh (Apr 18 2016 at 16:44):
I seem to recall it had something to do with extensions and/or multiple values....
Michel Rutten (Apr 18 2016 at 16:44):
https://thefhirplace.com/2013/03/16/attributes-versus-elements-in-fhir-xml/
Grahame Grieve (Apr 18 2016 at 18:07):
yes. we hate mixed content
Stephen Royce (Apr 18 2016 at 22:46):
I know this horse has _long_ bolted, but it is sad. Mixed content is not at all hard to handle and this "It is however, clearly more painful for those using JSON, where any member is now expanded to a complex object: "birthDate": {"value": "1973-05-31"}" is a ginormous pain in the butt when switching between formats. Somehow the argument for the more natural "birthDate": "1973-05-31" in JSON won but the not in XML. :(
Stephen Royce (Apr 18 2016 at 22:49):
P.S. The reason you want mixed content in XML is you can allow richer data, even allowing the value to be more XML if you need, e.g. <birthDate><year>1973</year><month>5</month><day>31</day></birthDate>.
Stephen Royce (Apr 18 2016 at 22:50):
(Which obviously breaks stuff, but just making the point.)
Grahame Grieve (Apr 18 2016 at 23:10):
mixed data is an absolute pain to handle
<code>
this
<extension .../>
that
</code>
Stephen Royce (Apr 18 2016 at 23:56):
This is not hard to handle. You can write rules that disallow it if you really want, but actually this is the power of XML and there's very specific rules about what something like that means and how it should be processed. All you need to do is handle text as a node. Anyway, the point is moot; it's clearly to late to change it and besides, JSON can't cope with data structures like that; it just would've been nice to maintain consistency with the JSON representation because, out of the box, most converters convert <birthDate>1973-05-31<birthDate> to "birthDate": "1973-05-31" and vice versa. As it is, to get a JSON format from native XML, I now have to use an intermediate step to convert a resource to XML that uses the hated mixed content and then convert to JSON (and vice versa).
Vadim Peretokin (Apr 18 2016 at 23:58):
You also have to consider the FHIR schema for several cases when converting anyway.
Stephen Royce (Apr 19 2016 at 00:00):
Not with the converter that comes built in to eXist. It just works out of the box (except for the nuisance value attribute thing).
Vadim Peretokin (Apr 19 2016 at 00:02):
I doubt it works correctly. How would it know to create a JSON array when there's just one XML value but the FHIR has a max multiplicity of *, for example
Stephen Royce (Apr 19 2016 at 00:03):
It's schema-aware, that's one of the reasons for using the schemaLocation in the internal storage.
Stephen Royce (Apr 19 2016 at 00:08):
Although, admittedly, the only resource I'm using in any significant way is StructureDefinition, so I may not have come up against any edge cases.
Last updated: Apr 12 2022 at 19:14 UTC
