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
[email protected]
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
