Hi, double checked the specs. Small correction to Heath,
AOM 1.4 Archetype.uid is HIER_OBJECT_ID, value have both root: UID and extension: String, more or less an II of HL7. But, he is right, UID can be UUID or OID. Ref: http://openehr.org/releases/1.0.2/architecture/rm/support_im.pdf page 32. AOM 2 Archetype.uid is UUID, besides tooling, hat makes AOM 1.4 spec incompatible with AOM v spec. Also the description of AOM v1.4 is wrong for Archetype.uid: "OID identifier of this archetype.", because it can be UUID or OID root, and also have an extension! Ref: http://www.openehr.org/releases/AM/Release-2.0.6/docs/AOM1.4/AOM1.4.html#_archetype_class Lastly, the AOM 1.4 spec doesn't say anything about the extension, so some archetypes might have c1315be0-203a-42e4-a6be-d5b0db05d27d::extension34232 or 2.1.123.342.235.456::extension342342 as uid. I think we might need to do an amendment like AOM 1.5 saying that extension should be empty and the UID should be UUID for Archetype.uid. About the schema, IMO that is a different topic since it is not related with the AOM spec. Still need to discuss good XML representations. On the other hand, we are focused on JSON right now for the REST API, so we might need to focus on JSON Schema more than XSD. - Pablo. On Wed, Jun 14, 2017 at 10:17 PM, Heath Frankel < [email protected]> 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- > [email protected]] *On Behalf Of *Thomas Beale > *Sent:* Thursday, 15 June 2017 5:40 AM > *To:* Openehr-Technical <[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 list > [email protected] > http://lists.openehr.org/mailman/listinfo/openehr- > technical_lists.openehr.org > -- Ing. Pablo Pazos Gutiérrez Cel:(00598) 99 043 145 Skype: cabolabs <http://cabolabs.com/> http://www.cabolabs.com [email protected] Subscribe to our newsletter <http://eepurl.com/b_w_tj>
_______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
