Stream: implementers
Topic: wire format (decoding resources)
Thomas Andersen (Jul 02 2016 at 19:59):
When a resource is profiled, and you would like to decode that resource into a custom class, the current wire format makes this hard. When you encouner a resource e.g. <MedicationOrder>, you need to wait untill <meta><profile> is read, before you can decide which type of profile the MedicationOrder belongs to. Would it be possible as part of STU3 to change the wire format a bit, in order to expose the profile sooner. E.g as part of <MedicationOrder profile="the main profile">.
Lloyd McKenzie (Jul 02 2016 at 21:27):
That would require identifying one of the profiles as "the main profile" - and multiple profiles could exist and could be considered "main" for different consumers. We *could* list them all in an attribute with space-separations, but you'd still have the same issue when parsing JSON. As well, unless you have a special arrangement with the sender, you can't count on the profile(s) you care about even being declared. Finally, having the data in meta makes it easier to exclude it from being included in digital signatures. You're free to submit a change request, but it might be a tough sell.
Lin Zhang (Dec 03 2016 at 11:33):
Could you please explain what is the wire format? Because it is hard to find a formal definition of the term, eps. for newbies. Thanks.
Paul Knapp (Dec 03 2016 at 12:24):
In an exchange there can only be one 'main' profile, it is only from a persistance perspective that more profiles could be asserted.
Lin Zhang (Dec 03 2016 at 23:27):
Sorry for duplicate posts due to the status remained "Sending".
Pascal Pfiffner (Dec 05 2016 at 14:55):
@Lin Zhang , the wire format simply means the format the resource is transported (“sent over the wire”). That is XML or JSON (or RDF).
(ah, ignore, just saw the other stream)
Lin Zhang (Dec 05 2016 at 15:36):
Thanks, Pascal :)
Last updated: Apr 12 2022 at 19:14 UTC
