I agree with you, except for how damn limiting pure json* is. Any attempt to introduce long-ints or annotation take you to vertical-specific json+.
* json is javascript, so has type and other limitations. On Fri, Feb 15, 2019, 7:39 PM Bert Verhees <bert.verh...@rosa.nl wrote: > A few last words on this. > > It is easy for JSON based archetype repository to cooperate with an ADL > based repository. Serializing of an AOM structure to ADL is very easy to > do, this counts for the DADL and CADL part. The other way around, to > convert the ADL definition part to JSON is harder, that involves the > parser-code and grammars which are hard to maintain. > > It is fragile code. > > I remember how hard it was to get stable grammars ready, about two years > ago, and they are also hard to test. You can only test the grammar and the > generated code after having written thousands of lines derived code and > test that. This is not unit-testing. There is a lot of untested code in a > parser. > > I know from own experience, I already wrote a few times an ADL parser, > also other parsers, in Java and golang, it takes a year or more. Pieter is > working two years on it, of course not every day, but still. It is really a > lot of complex code. I remember a year ago he was using a visitor pattern, > now he left that. That was quite a big change. While doing it he finds out, > and he does a very good job. He is a very good programmer but with a > difficult task. > > And even small updates in a grammar can cause great code change, many > difficulties. > It does, in my opinion, not belong in a modern programming environment > where simplicity, maintainability and testability are important goals. > > Only changing a few simple paradigms can make thousands of lines of code > difference. > > The elegance of proven technology of worldwide programming effort over > many years. The simplicity of JSON guarantees easy controllable and > maintainable (sustainable) code. > > But, as said, for purpose of readability is it easy to serialize to ADL > code, if that is an argument. > > Why do I write all this. > > I am writing a generic multi purpose BMM/AOM kernel as a hobby project, I > work an hour a day on it, sometimes less, I have a job also. > > I do not want to write an ADL parser because I don't need it. It saves > months of work. The code I write, which can also serve OpenEhr or ISO13606 > or CIMI in any version, or accountancy software or many other can be read > by a novice programmer, so simple it is. > > And I think that is how code should be. Easy to test, easy to debug, easy > to read, easy to understand. > > That is my story, I wanted to see how other people think about these > ideas, thanks for sharing your opinions. > > Best regards > Bert > > Sent from my Xperia™ by Sony smartphone > > > ---- Bert Verhees wrote ---- > > Sent from my Xperia™ by Sony smartphone > > > ---- Original Message ---- > Subject: Re: JSON for definitions-notation > Sent: 15 Feb 2019 22:46 > From: Bert Verhees <bert.verh...@rosa.nl> > To: Pieter Bos <pieter....@nedap.com> > 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 <thomas.be...@openehr.org>: > > 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 >
_______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
