Attributes versus elements in FHIR Xml

Some of you have asked me why, since our latest (0.7) Fhir Xml format, we use attributes to contain most of the “primitive” values, instead of the somewhat more common elements. E.g. for birthdate we now use:

<birthDate value="1972-11-30"/>

instead of:

<birthDate>1972-11-30</birthDate>

The reason is simple: extensions. Since any element in Fhir can be extended, there’s no such thing as a true “primitive” element. We might extend birthDate, so we could also include the original text as input by the user:

<birthDate value="2013-03-22">
    <extension>
        <url value="http://dontuse.example.org/profile/@narrative#originalText" />
        <valueString value="sometime next week" />
    </extension>
</birthDate>

If we wouldn’t have put the actual value in an attribute, we would end up with mixed content for birthDate:

<birthDate>
    2013-03-22
    <extension>
        <url value="http://hl7.org/fhir/profile/@narrative#originalText" />
        <valueCode value="sometime next week" />
    </extension>
</birthDate>

Handling mixed content is a pain for most of us, so we choose to use the “value” attribute over allowing mixed content.

Whether this really is out of line with current Xml authoring style is unclear: discussions on this subject on stackoverflow show a wide range of opinions, some even prefer to always put primitive values in attributes. 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"}

instead of the more natural

"birthDate": "1973-05-31"
Advertisements

3 thoughts on “Attributes versus elements in FHIR Xml

  1. grahamegrieve

    Well, yes, but we already had foregone the opportunity for the more compact json representation because any primitive would need to have an id attribute anyway, so “birthDate”: “1973-05-31” was never an option 😦

    Reply
  2. Peter Bernhardt

    As someone authoring a derivative spec where JSON is the only format we’ll support, yes, I do find this unnecessary and burdensome. Ewout, I understand that you’ve written a good C# parser for this that eases the pain – but what about Java, Perl, PHP, Python, etc? And to Grahame’s comment, do you really need an id attribute on a date? I know that’s just a simple example, but doesn’t defining a type as a CodeableConcept address the edge cases? i believe you folks have done an outstanding job with FHIR, but I’m very worried that something like this will give people pause – or force them to adopt XML as their only supported format. That the important goal at the heart of the FHIR spec – simplicity – has been sacrificed by this design decision.

    Reply
    1. ewoutkramer Post author

      Hi Peter, since we want to be able to refer to primitive values from the narrative, even primitives need to be able to receive id’s. They can also be extended, a good example would be an extension on a simple string to indicate the language. Another example is an extension to encode a null flavor on any primitive value…. it’s certainly not my favorite part of the design, but it’s too early to say we are not going to need it. That being said, DSTU is there to see whether this turns out to be a major pita and decide whether its advantages are worth the trouble…

      Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s