Thanks very much for your reply. I did find a link on this which help to study this more.
https://stackoverflow.com/questions/13502398/json-integers-limit-on-size/39681707#39681707 Of course this is not a problem on archetypes but on datasets it can be. Also worth considering is that there are more kinds of JSON like for example GeoJSON. And there is JSON for expressing mathematical operations. Useful for storing mathematical procedures in a database. Best regards Bert Sent from my Xperia™ by Sony smartphone ---- William Archibald wrote ---- >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
_______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
