FHIR Chat · Background on why element order matters in XML? · implementers

Stream: implementers

Topic: Background on why element order matters in XML?


view this post on Zulip Cooper Thompson (Jan 19 2017 at 20:45):

Currently, in FHIR XML, the elements are required to be in a fixed order. In JSON, they are not (except resourceType). Is there any background on why XML order matters? I expect this has been discussed and there is a good reason, we'd just like to understand what was considered.

view this post on Zulip Lloyd McKenzie (Jan 19 2017 at 21:42):

It's a requirement of XML schema. XML schema doesn't support unordered elements if any of them repeat. You can get around that by having a "wrapper" element, but XML people generally find that ugly/unappealing.

view this post on Zulip Lloyd McKenzie (Jan 19 2017 at 21:42):

It was talked about at length

view this post on Zulip Grahame Grieve (Jan 19 2017 at 23:10):

also to support sax. we would much prefer to be able to impose order on json to enable efficient processing, but can't

view this post on Zulip Vadim Peretokin (Jan 20 2017 at 09:37):

XML itself is order-sensitive, so any questions about that are whenever you want to kludge it to make it order-insensitive like Llyod mentioned, not whenever you want to impose ordering

view this post on Zulip Cooper Thompson (Jan 20 2017 at 14:43):

@Vadim Peretokin I don't believe XML itself is order sensitive. The order is enforced in the XSD using xs:sequence. FHIR could support unordered XML if our XSD allowed it. But looking more into how you have to build your XSD to support unordered repeating elements, I see Lloyd's point.

view this post on Zulip Vadim Peretokin (Jan 20 2017 at 14:48):

You're right, technically the XML spec says nothing about it - though in practice every parser would preserve it (http://lists.xml.org/archives/xml-dev/201003/msg00045.html)

view this post on Zulip nicola (RIO/SS) (Jan 20 2017 at 15:08):

XML is human unkind - hash-map (key value) has unordered semantic. That's why hipsters like json or something like this (yaml, edn)- it's naturally fit in memory datastructures for objects, struct, records etc. Modern REST API ignore XML at all (google, facebook, etc), i do not know why FHIR community keep it and make reference. My opinion, primary format should be JSON, if we are targeting modern web developers, xml should be jsonified!

view this post on Zulip Lloyd McKenzie (Jan 20 2017 at 15:27):

@nicola (RIO) FHIR's committed to supporting both because there are considerable communities that wish to use both. And we've also committed to ensuring that each syntax feels as right as it can to its particular community. Discussion about the pros and cons should be limited to change requests enhancing the guidance for implementers in choosing which syntax(s) to support if they're not sure - and those should be expressed in neutral terms :)

view this post on Zulip nicola (RIO/SS) (Jan 20 2017 at 16:19):

Thank you, @Lloyd McKenzie - my fault.

view this post on Zulip Lloyd McKenzie (Jan 20 2017 at 17:00):

No worries - just don't want to get bogged down in something that'll divert us from getting R3 out the door.

view this post on Zulip Marc de Graauw (Jan 21 2017 at 13:56):

There's was older thread on this on xml-dev, where Tim Bray clearly states that XML element order is significant in practice (all software preserves it), though the spec is indeed unclear (as @Vadim Peretokin says too): http://lists.xml.org/archives/xml-dev/200101/msg00863.html


Last updated: Apr 12 2022 at 19:14 UTC