Stream: implementers
Topic: AVRO, json, polymorphic elements
nicola (RIO/SS) (Feb 06 2017 at 05:36):
*ideomatic polymorphics encoding* in AVRO (unions in it's terms) - http://avro.apache.org/docs/1.8.1/spec.html#json_encoding. I think, it will be quite easy to add avro to FHIR
Grahame Grieve (Feb 06 2017 at 06:26):
well, that would be the long form with the type name instead of the value name. Interestingly, that's exactly how the json-ld form does it, and it was always my preference. But we were assured that no one who understood json would ever do that
Grahame Grieve (Feb 06 2017 at 06:26):
too late to change now
nicola (RIO/SS) (Feb 06 2017 at 07:26):
May be add new json/v2 format, so we do not break existing codebase?
Grahame Grieve (Feb 06 2017 at 07:49):
json-ld is a new format for that reason. have you looked at it?
nicola (RIO/SS) (Feb 06 2017 at 08:08):
Yes, it looks much better than current json format :)
Grahame Grieve (Feb 06 2017 at 08:56):
I like it too, but I don't think it's got legs. Committee says that we'll let people look at it and think
Josh Mandel (Feb 06 2017 at 16:43):
Why doesn't it have legs (and if it doesn't: why do you like it @Grahame Grieve)?
Grahame Grieve (Feb 06 2017 at 19:24):
I just don't think there's interest in changing the existing json format, and while I like the json-ld format for it's regularity against the underlying FHIR model, it's more complicated on the surface.
Grahame Grieve (Feb 06 2017 at 19:25):
also, its more verbose because we have to qualify the element names - this will change when the next version of json-ld allows redefinition of names in contexts based on scope.
Grahame Grieve (Feb 06 2017 at 19:25):
probably R4 for us
nicola (RIO/SS) (Feb 06 2017 at 19:53):
I will predict interest, when people will try to really implement at least FHIR storage in databases with native support of json :)
Grahame Grieve (Feb 06 2017 at 19:55):
however the json-ld format is... ruined... by the RDF world's refusal to do lists properly
nicola (RIO/SS) (Feb 06 2017 at 19:59):
The is some concern for me - there are a lot of nice formats - like edn, yaml, avro - most of them are suppersets of json and it would be good to support all of them - at least give some guidelines to deduce such formats from good json
Vadim Peretokin (Feb 06 2017 at 19:59):
Define support - everyone should be able to communicate and understand them?
nicola (RIO/SS) (Feb 06 2017 at 20:01):
We need some rules to deduce and serve json-like formats. Most of them could degrade to json.
nicola (RIO/SS) (Feb 06 2017 at 20:05):
@Vadim Peretokin modern web understands and communicates this formats well :)
nicola (RIO/SS) (Feb 06 2017 at 20:06):
And this is in the heart of REST arch style - decouple representation from information
Vadim Peretokin (Feb 06 2017 at 20:07):
Well I'm out of my depth here because the modern web changes its opinion on an annual basis
nicola (RIO/SS) (Feb 06 2017 at 20:08):
Not too quickly - yaml here for about 10 years, edn - 7, avro and graphql are very perspective
Vadim Peretokin (Feb 06 2017 at 20:10):
That's just when they were created. When they are fashionable and no longer fashionable is the problem :P
nicola (RIO/SS) (Feb 06 2017 at 20:13):
I do not agree - xml is archaic, json is too add-hock - time requires well-designed formats! The best from my point of view is edn.
Vadim Peretokin (Feb 07 2017 at 10:40):
Won't argue with xml and json, that is true, but the topic started out about adding AVRO and now edn is the best...
Last updated: Apr 12 2022 at 19:14 UTC
