These are all very good reasons.

So I make an ADL serializer, so I can always represent my archetype ADL for archive purpose. But the complexity of the parser, that I don't want anymore. Life is short. And there are better things to do.

As said, I am building an BMM/AOM environment as a hobby project, just for fun. I don't know where I will end up. But one of my important goals is to avoid complexity.
We'll see where it goes too.

I started this discussion yesterday with the question if there are technical objections to represent archetypes in JSON. I was not sure that I was overseeing it all. Now I am, and I understand that there are no technical objections, so that makes me glad.

have a nice day
Bert

On 16-02-19 15:10, Thomas Beale wrote:


On 16/02/2019 14:00, Bert Verhees wrote:
On 16-02-19 13:20, Thomas Beale wrote:

Have a look at the Archie project <https://github.com/openEHR/archie>, you'll find very vanilla Java facilities used to do most of this work.

Thank you for pointing this out. But I already knew this. My point is not that it is easy to dump an ADL archetype via a parser to a JSON representation. My point is that the JSON representation must be the result and working modus of archetype/data-handling, in the archetype-designer and in the repositories. So the ADL parser and all that complex code around it becomes superfluous. There should be no temptation to do any processing with ADL.

Even in tools that read ADL archetypes, hardly any of the processing is done in ADL, it is done on the in-memory AOM structure - that's true both in Archetype modelling tools and runtime validation tools.

The utility of ADL as a syntax, apart from being human-readable (at least for those who understand the semantic basis of archetypes) is that it never changes, whereas object syntaxes, XML etc are changing all the time. This month we are using this flavour of JSON, next month it is another flavour. Next year, everyone decides they like YAML instead. IT is mostly a fashion show of these kinds of changes.

It's the same with programming languages - their syntax changes only with the semantic changes (e.g. Java 1.5 -> 1.8), but not with compiled representation.

So I am all for using JSON or whatever in the way that you say, but we should just remember that such syntaxes are machine formats optimised for something, and they will always be replaced by another format(s) optimised for something else. Saving out to ADL can be very useful sometimes, in case you want to guarantee to preserve semantics across these changes.

The other reason ADL exists is that it is a lot easier for humans to learn the archetype formalism via the ADL specification than the AOM specification, even though the latter is the one containing most of the formal semantics.

- thomas



_______________________________________________
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


--
*Bert Verhees*
Software developer, architect

Profile: https://www.bertverhees.nl/

Twitter: https://twitter.com/VerheesBert
LinkedIn: https://www.linkedin.com/in/bertverhees/
Email: bert.verh...@rosa.nl <mailto:bert.verh...@rosa.nl>
Mobile: +31 06 28050294
_______________________________________________
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Reply via email to