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.
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?
Hi David, Personally I don’t think UIDs are needed; checking if an archetype has changed is easier to do with an MD5. UIDs are mostly a distraction. But some people and more particularly governments like them. So if we include them in the AOM, then I guess they have to work. So making them optional won’t work - because they can’t be generated from anything, you have to ‘have them’ which means they have to have been created at the right point in time, usually by the creator or modifier of some artefact. I don’t see any utility in mixing UIDs into the human-readable ID (HRID) either in models or in data. They aren’t shorter, and you can’t infer anything from them as you can with the HRID, and noone who needs to inspect data (as inescapably happens routinely in integration development work) can easily work with UIDs. So their utility is largely imaginary in my view. But not everyone agrees with that… - thomas
What you refer to as version+revision+build is called majorVersion.minorVersion.patchNumber in SemVer.
In addition you can have a "-alpha" flag to indicate that the archetype is still unstable.
In this unstable mode a build id is necessary if you want to uniquely identify one particular instance of an archetype - there could e.g. be many 1.0.1-alpha (but only one 1.0.1 or 1.1.0 or 1.0.2).
This is just SemVer as far as I am aware.
So the complete revision could be e.g. 1.0.1-alpha+BUILD where build is e.g. a UID which changes each time (in a CKM environment on each upload), even if nothing else in the complete revision number changes.
Thomas has called this build uid instance id in his initial email.