Hi Thomas, I agree. I would see the uid as being a reasonable option inside systems but the multi-axial Id is what should be exposed externally.
The use of the new scheme is going to make it much easier for tooling to adapt to working with the different levels of version control that are required as an archetype goes through the development cycle, so even if system implementers decide not to use unstable archetypes, tooling definitely will, with a necessity to handle some of the inevitable dependencies in slot-filling etc. At the moment this is done by using the archetype MD5 hash in the archetype to ensure that the parent container is referring to exactly the correct version of the archetype (which can get very complex in an archetype dev environment with multiple iterations). This works but is a pretty blunt tool which can be over-sensitive to what we consider to be minor changes as editors. The new system should allow us to work fairly loosely while the archetype is in turmoil i.e only check that we are using the correct major version, then gradually tighten the constraints as it reaches maturity prior to publication. You see similar arrangements in package managers like RubyGems and NPM, and having good alignment with something like semver should allow us to make use of some of the open source code underpinning these tools. We are often accused (unfairly) of using non-standard technologies, and I think this is one area where sticking with a de-facto standard will pay dividends with the next version of tooling. Ian On 3 October 2014 17:36, Thomas Beale <thomas.beale at oceaninformatics.com> wrote: > On 03/10/2014 16:40, Ian McNicoll wrote: > > > When this published v1 archetype needs to go back into review it gets > labelled as > > > org.openehr::openEHR-EHR-OBSERVATION.lab_test.v1.0.1-unstable+build.e34dgtj67856 > > or using the uid - > 123rhturytu55634567.v.1.0.1-unstable+build.e34dgtj67856 > > > Probably a side issue from Ian's main points, but.... > > I think that at the system interface (i.e. in any web service interfaces), > we should stick to > org.openehr::openEHR-EHR-OBSERVATION.lab_test.v1.0.1 > > not UID-based archetype ids. Internal to the system, a translation might > be done from the above id to e.g. an instance UID, or something entirely > different, that the system wants to use. > > When AQL queries are built, and when data are shared between systems, the > multi-axial id should be used - think of it as a safe symbolic id. Actual > data can have whatever it likes as ids, as long as it can translate > properly between what it uses internally and what the outside world uses. > > - thomas > > > _______________________________________________ > openEHR-clinical mailing list > openEHR-clinical at lists.openehr.org > > http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org > -- Dr Ian McNicoll office +44 (0)1536 414 994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical Modelling Consultant, Ocean Informatics, UK Director openEHR Foundation www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL SCIMP Working Group, NHS Scotland BCS Primary Health Care www.phcsg.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141003/7ab39da1/attachment.html>
