Sent from my Xperia™ by Sony smartphone
---- Original Message ---- Subject: Re: JSON for definitions-notation Sent: 15 Feb 2019 22:46 From: Bert Verhees <[email protected]> To: Pieter Bos <[email protected]> Cc: Not many people find archetypes readable. I can read them and I have done that many times, but most modelers I know are lost in a second when they see ADL text, I have seen that many times too. But it is more readable than Xml or JSON, I agree. For readability I would like to promote a documentation protocol, modeling tooling should take care for that. That should not be the purpose of an archetype. The archetypes in code are for machine processing, that should be the main purpose, and this purpose should be exercised to a maximum of simplicity and efficiency. I was thinking about the type information ADL has, if it has function in validating datasets. I don't think so, and I think it can be omitted. For validating-purpose it is not needed. An archetype is a tree of properties to properties ending via cardinality to leaf nodes. That is the information that is needed and JSON can deliver that without diverging from the object dump idea. All that information is already in AOM. This has as result that archetypes can be read in AOM without need of parsing. I was also thinking about the name-convention, but that is a reference model (BMM) issue. The naming convention in the reference model will be used in datasets. BMM is very powerful, it extends the purpose of reference models and archetypes to virtually every domain, also OpenEhr 😉. It is in fact a wonderful invention, especially in combination with NoSql databases, but it needs a simplicity overhauling for efficiency and general connection to programming eco systems or standards can be achieved by using its conventions. Bert Sent from my Xperia™ by Sony smartphone ---- Pieter Bos wrote ---- >Archie offers a json serializer and deserializer. For Odin they are present as >well, but has not been tested with archetypes, may need a small bit of work. >Yaml should be a matter of adding a dependency and configuring it. >We're still working on XML - the bindings are there and it works, but the AOM >schemas have not been finished yet so there will be changes, see the >specifications-ITS-XML repository on GitHub for details. > >One could argue ADL is easier to read and write by humans than json, yaml, >Odin or XML. The other formats have a lot more tools available. Good thing we >have both. > >Regards, > >Pieter Bos > > > >Op 15 feb. 2019 20:41 schreef Thomas Beale <[email protected]>: > >JSON, YAML and ODIN are all just object-dump serial formats that result from >traversing an in-memory object graph, so it is a generic operation to generate >them from tools (XML is more problematic due to being irregular in many ways >and being schema-dependent). > >In the case of archetypes, the dump is just of objects that are instances of >the >AOM<https://specifications.openehr.org/releases/AM/latest/AOM2.html#_the_archetype_package>, > i.e., ARCHETYPE, C_ATTRIBUTE, various kinds of C_OBJECT and so on. > >The ADL Workbench has an export mode (for I think around 5 yeras) that >generates the first 3 for any archetype, and also a whole archetype library. >The folks doing CIMI use at least the JSON mode. It also generates XML, via >custom serialiser. > >One of the jobs I never completed is a deserialiser for the 3 regular formats, >but it is nearly trivial. I am not sure if Archie or Marand's ADL-designer >tools do the same but I think it should be trivial for them to implement as >well. > >I will look into this again... > >- thomas > >On 15/02/2019 18:51, Bert Verhees wrote: >I always admired OpenEhr for its ability to notate archetype-definitions and >now also BMM definitions in any type. > >I saw experiments in XML, but the official endorsed notation language is ADL. > > >I wonder, would it also be possible to write archetypes and reference-models >in JSON? > >If so, it would save us tons of code, no grammars needed, no parsers needed. >Many programming languages support JSON out of the box, with only some >annotations needed. NoSQL Databases often support JSON, and have their own >JSON-path based hierarchical query-languages. > >Venkat Subramaniam, who is a java-guru, said: "Don't walk away from >complexity, RUN!!!" > >But Einstein said: "Everything Should Be Made as Simple as Possible, But Not >Simpler" > >So the question is: Are there any technical objections to express archetypes >and reference-models in JSON? > >Best regards > >Bert Verhees > > >_______________________________________________ >openEHR-technical mailing list >[email protected]<mailto:[email protected]> >http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > >-- >Thomas Beale >Principal, Ars Semantica<http://www.arssemantica.com> >Consultant, ABD Project, Intermountain >Healthcare<https://intermountainhealthcare.org/> >Management Board, Specifications Program Lead, openEHR >Foundation<http://www.openehr.org> >Chartered IT Professional Fellow, BCS, British Computer >Society<http://www.bcs.org/category/6044> >Health IT blog<http://wolandscat.net/> | Culture >blog<http://wolandsothercat.net/> | The Objective >Stance<https://theobjectivestance.net/> > >_______________________________________________ >openEHR-technical mailing list >[email protected] >http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
_______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
