Seems that the story is not finished yet. Someone in a project I work made the joke to rename HIER_OBJECT_ID to ANY_KIND_OF_ID, because it can represent almost any type of id.
What is the official defined purpose of the Archetype.uid property? Op 15 jun. 2017 19:41 schreef "Pablo Pazos" <[email protected]>: > Hi Bert, when using ISO OIDs, UUIDs are not one arc OIDs since they have > to start with a specific arc 1. or 2. > > http://www.oid-info.com/cgi-bin/display?tree= > > On Jun 15, 2017 4:33 AM, "Bert Verhees" <[email protected]> wrote: > >> Although the OID and UUID as used in the archetypes are (in the most >> simple (one arc) OID-occurrence) technical interchangeable is their >> semantical meaning completely different. So what do we want to express >> here? Is it ever used in the way a OID is meant to be used? (to trace back >> the organization that is responsible for creating/maintaining the archetype >> and assign a purpose/meaning to the archetype) >> >> The OID is a paper tiger, it suggests something, with structured meaning, >> but no organization I know has the overhead of maintaining useful use of >> OID's in archetypes implemented. That is why, also, they do not occur in >> CKM and no-one ever complained about that, for ten years. No software I >> know is interpreting the arcs of the OID in the uid-property of an >> archetype, it would run into trouble when it did. The tooling (including >> CKM) has no way to support administrative overhead. >> >> That the use of OID in the uid-property of archetypes is not useful, is >> illustrated by replacing the OID by a UUID in ADL/AOM 2.0.x >> >> When remaining to the OID in 1.4.x, we create an illusion, we suggest >> some structure in the uid-property which is not there. In fact opposite, we >> suggest that all archetypes are to be maintained by different organizations >> because they have a different uid and only one arc. >> >> The problem I have is that the current situation with OID in the >> uid-property corrupts the administrative use. We write a UUID, we call it >> OID but we treat it as a UUID, because the practical use does not allow to >> see it as a meaningful structure. >> >> Bert >> >> >> >> >> On 15-06-17 03:17, Heath Frankel wrote: >> >> Hi Thomas, >> >> Your statement that the use of HIER_OBJECT_ID in the AOM1.4 spec is used >> for OIDs is incorrect. HIER_OBJECT_ID is a complex type with a value >> attribute of type UID, which may be either UUID, ISO_OID or INTERNET_ID. >> >> >> >> The bigger issue is the HIER_OBJECT_ID is incompatible with UUID from a >> XML schema perspective as UUID is a simple type with a restricted string >> value while HIER_OBJECT_ID is a complex type with a child element value. >> The V1.4 AOM XML schema uses this HIER_OBJECT_ID type (as per the AOM >> specification) and since the OPT schema inherits this model, it also uses >> this type and all OPTs generated by CKM (and the template designer) >> populate the uid element with the template GUID specified in the OET file. >> >> >> >> I suggest that the ADL 2 specification is that one that needs to change >> or there needs to be a specified mapping between the two. >> >> >> >> Regards >> >> >> >> Heath >> >> >> >> *From:* openEHR-technical [mailto:openehr-technical-boun >> [email protected] <[email protected]>] *On >> Behalf Of *Thomas Beale >> *Sent:* Thursday, 15 June 2017 5:40 AM >> *To:* Openehr-Technical <[email protected]> >> <[email protected]> >> *Subject:* AOM 1.4 - Archetype.uid a UUID or OID? >> >> >> >> >> >> Bert picked up an anomaly in this PR >> <https://openehr.atlassian.net/browse/SPECPR-219> that I think should >> probably be fixed. ARCHETYPE.uid is of type UUID in the AOM2 spec, but of >> type HIER_OBJECT_ID in the AOM1.4 spec (the latter type is the openEHR type >> for OIDs). However it appears that all ADL1.4 archetypes that have a uid >> have it as a Guid (i.e. UUID), and I assume the various tools do as well. >> We avoid Oids like the plague in openEHR, and I am not aware of them being >> used anywhere. >> >> If we can verify that everything assumes a UUID for this field, then the >> spec is wrong, and we should update it from 1.4.2 to 1.4.3, i.e. treat this >> as an error correction. >> >> Could tool makers check this issue and report here? >> >> thanks >> >> - thomas >> >> >> >> -- >> Thomas Beale >> Principal, Ars Semantica <http://www.arssemantica.com> >> Consultant, ABD Team, Intermountain Healthcare >> <https://intermountainhealthcare.org/> >> Management Board, Specifications Program Lead, openEHR Foundation >> <http://www.openehr.org> >> Chartered IT Professional Fellow, BCS, British Computer Society >> <http://www.bcs.org/category/6044> >> Health IT blog <http://wolandscat.net/> | Culture blog >> <http://wolandsothercat.net/> >> >> >> _______________________________________________ >> openEHR-technical mailing >> [email protected]http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >> >> >> >> _______________________________________________ >> openEHR-technical mailing list >> [email protected] >> http://lists.openehr.org/mailman/listinfo/openehr-technical_ >> lists.openehr.org >> > > _______________________________________________ > openEHR-technical mailing list > [email protected] > http://lists.openehr.org/mailman/listinfo/openehr- > technical_lists.openehr.org >
_______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
