In 1.4 the description of Archetype.uid saying "OID..." is incorrect. It should say "UID root with no extension".
On Jun 15, 2017 7:50 AM, "Thomas Beale" <[email protected]> wrote: > > 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 > > > > > > _______________________________________________ > 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
