Excellent work, many thanks for all the effort your team put into this library. Could you clarify something? When you say an operational template, do you mean a flattened archetype as per ADL 2.0? (that’s the impression I got looking at the code)
I’m a bit behind re adl 2.0; does your implementation imply that an opt according to 2.0 specs is no different than an archetype? I can see that you declared some xml bindings in your OperationalTemplate class which seam to refer to type names from opt 1.4 .
In summary I’m a bit confused Could you briefly explain how Archie team sees the relationship between opt 1.4 and 2.0 ?
I mean OPT2, which is according to the ooenehr specifications a flattened archetype with extra operations performed on it, such as including and flattening all archetype roots in the same tree, including their terminologies,and replacing all use_node with a copy of the tree to be used. Very useful. Can be expressed in ADL.
Archie does not support the 1.4 xml OPT format.
Note that xml bindings are in place for the AOM, but I wouldn’t use them for interoperability because they were written before an official xsd has been published - I’m actually not sure if an official AOM 2 xsd currently exists.
Note that there is also the concept of a template, which is also an archetype, but is different from an operational template - templates are authored, opts are generated, often generated from a template.
I mean OPT2, which is according to the ooenehr specifications a flattened archetype with extra operations performed on it, such as including and flattening all archetype roots in the same tree, including their terminologies,and replacing all use_node with a copy of the tree to be used. Very useful. Can be expressed in ADL.
I did not realise that opt2 was fully defined. I thought it was ongoing work. I’ll have to go and check it now
Archie does not support the 1.4 xml OPT format.
Thanks for the clarification.
Note that xml bindings are in place for the AOM, but I wouldn’t use them for interoperability because they were written before an official xsd has been published - I’m actually not sure if an official AOM 2 xsd currently exists.
Could you please clarify which official XSD you’re referring to? AOM2?
Note that there is also the concept of a template, which is also an archetype, but is different from an operational template - templates are authored, opts are generated, often generated from a template.
Hmm. I guess this means opts lose some information regarding their lineage.
On the question of OPT2, it’s fully defined from the point of view of ADL2, which is to say that if you run the ‘flatten’ operation on an ADL2 source template, it generates something for you, which can be serialised in ADL2, ODIN, JSON, YAML and XML (the ADL WB does this, and I didn’t check, but I assume Archie replicates these).
However… there is the question of post-processing the flattened output (‘Raw OPT’ in the diag below) to do things like choosing/reducing languages, possibly removing annotations, reducing terminology bindings, potentially replacing inline at- and ac-codes with their binding values (i.e. concept or value-set refs from actual terminologies).
See here in the OPT2 spec. These post-processing stages are what need further specification.
The AOM2 XSD is here, which I think is the one I wrote some years ago, possibly amended by others since. I doubt if this has undergone sufficient rigorous testing to be considered entirely reliable yet.
With respect to preserving lineage in templates, this was contemplated in the Archetype Identification spec, but not integrated into any other specification at this stage.
However... there is the question of post-processing the flattened output ('Raw OPT' in the diag below) to do things like choosing/reducing languages, possibly removing annotations, reducing terminology bindings, potentially replacing inline at- and ac-codes with their binding values (i.e. concept or value-set refs from actual terminologies).
The current OPT 2 specification says even the specialization statement should be removed from an OPT. I ignored that at least in the AOM when implementing operational templates, to need source forms of archetypes slightly less often
Could you briefly explain how Archie team sees the relationship between opt 1.4 and 2.0 ?