AOM 1.4 - Archetype.uid a UUID or OID?

Thomas Beale thomas.beale at openehr.org
Thu Jun 15 06:49:45 EDT 2017


On 15/06/2017 02: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.
>

Right. I was skimming over that detail... I remember now the logic of 
this choice - we originally thought we should accommodate UUIDs (Guids) 
and OIDs, which does require a HIER_OBJECT_ID in the openEHR type system.

> 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.
>
>

from the point of view of continuity, that is probably correct. However 
we wouldn't need to do that just in order to maintain XSD compatibility 
- we can maintain the XSD HIER_OBJECT_ID type in that field, in a 
version of the AOM2 XSD that aims to be compatible with the AOM1.4 XSD, 
while in a more efficient AOM2 XSD which we might write, it would just 
be a restricted string field, i.e. a UUID.

I am more inclined to make the AOM2 specification, which is normative, 
as clean as it can be. And since it has other breaking changes, having 
this one as well is not problematic.

I also think that the AOM1.4 spec is correct as it is, given what Heath 
says above. So really it comes down to how we treat XSDs and XML, not 
the normative models of archetypes.

- thomas


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20170615/1ecd43a4/attachment-0002.html>


More information about the openEHR-technical mailing list