Hi, I was not aware of this addition. It is clear that having these UIDs it will be simpler to check if the archetype has changed, as you say. But is it also the intention of these UIDs to be used to fill the archetype_id attributes in the RM instances? Or the link between the instance and an specific archetype will be done using the traditional archetype identifier+version+revision+build? Moreover, if now we will have unique identifiers with version+revision+build, why do we need an additional UID?
David 2014-11-17 14:44 GMT+01:00 Thomas Beale <thomas.beale at oceaninformatics.com>: > > We are finalising the last details of the ADL 2/AOM 2 specifications for a > Trial release. One detail is the question of UIDs. The current AOM 2 > specification shows two UIDs: provenance_id and instance_id. The former is > created at archetype creation and never updated, even with major archetype > version changes, meaning that it can always be used to track an archetype, > including all versions and copies, through time. > > The latter is updated every time anything at all changes with the > archetype. > > *The question here is: should these two ids be mandatory in ADL 2? *I > believe they should, since they enable tooling to track archetypes and > archetype changes properly. Previously, when the specs where identified as > ADL 1.5, we had them as optional, for reasons of backwards compatibility, > but having moved to ADL 2, we no longer have this requirement. > > - thomas > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > -- David Moner Cano Grupo de Inform?tica Biom?dica - IBIME Instituto ITACA http://www.ibime.upv.es http://www.linkedin.com/in/davidmoner Universidad Polit?cnica de Valencia (UPV) Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta Valencia - 46022 (Espa?a) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141118/f0d8c45d/attachment.html>
