The object dump is a common use-case for JSON. There a few things that are needed more then the object dump.
What we would still need is standardised naming-notation of classes and properties, so there cannot be a conflict on that. I think the current format used in OpenEhr is very good, although not the same convention as in Java, but that is a minor issue. JSON can, besides using for object-dumps offer also space for meta-information, like type-information. The class name of an object for example, is such information which programmers often use. In Java it is by the instanceof-operator. Other ecosystems have similar operators. So to use JSON for archetype notation some things must be agreed on. I would be happy with such agreements. The advantages of JSON are huge. Except from the easy standard implementation there are many libraries and very efficient. Also inserting JSON in JSON makes flattening and template creation a matter of a few lines of code. And validating routines can partly be easily generated in memory and applied on JSON datasets. The only part that need grammar and parsing are the leaf and cardinality constraints. These are easy to define and parse and can be extracted from the current grammars. Bert ---- Thomas Beale wrote ---- 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 openEHR-technical@lists.openehr.org 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 openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
