On 01/10/2014 16:44, Sebastian Garde wrote: > Hi Sebastian, > > I realise you are physically not too far away from me in Germany and > we even share the same name, so I hope you won't shoot the messenger > here, but I have to say the following... > > The consequence of what you are saying would be that we cannot publish > any v1 archetype if it is already on CKM without an analysis if there > have been any breaking changes anywhere during the development and > review process (which would be the case in most cases I suspect). > > However, this is the case with or without any of the changes being > discussed here: It doesn't matter if draft archetypes become v0 for a > while: once they are published they'd be v1 again anyway - and likely > incompatible with the previous v1.
but none of the existing CKM archetype ids has a namespace, so the new ids will be distinguishable from the old. It would be useful to have some real data on who has used any CKM draft (i.e. 'old') archetypes in real systems to know is there is in fact a problem here or not. Anyway, the renaming should follow the model: openEHR-EHR-ADMIN_ENTRY.encounter.v1 => *org.openEHR::*openEHR-EHR-ADMIN_ENTRY.encounter.*v0.0.1* => review & changes => *org.openEHR::*openEHR-EHR-ADMIN_ENTRY.encounter.*v1.0.0* so there is no way for the first and last versions to get mixed up that I can see. > If on the other hand, you leave the CKM draft archetypes as v1 and > they are published subsequently, there is also no guarantee whatsoever > that the published version is compatible with any draft revision (or > any of the draft revisions with each other). > Either way, if you use them now, no, you cannot just replace a draft > archetype with the next revision of the draft archetype or its > subsequently published revision. You cannot do it now, because there > is no guarantee that they'd be compatible and you cannot do it with or > without v0. > > So, while I certainly acknowledge the problem (more below), it is not > a problem that is caused or increased by migrating draft archetypes to > v0. > > And in fact solving this problem is one of the core reasons for the > proposed revisioning rules. > You will know exactly where you are at and how compatible two > archetypes are. > > So, if you as a company use draft archetypes, this is the risk you > have taken - draft archetypes just cannot be assumed stable or > backwardly compatible just because they happen to be expressed in > (more or less) correct ADL. > The impression that draft archetypes are stable has of course been > given by the lack of activity in getting draft archetypes published on > the international CKM. > The industry sprint will hopefully change the momentum of this > considerably. > > The problem you describe is more or less the same for every vendor > that uses unstable archetypes, which for lack of alternatives, will > most likely be about every vendor. > > However, I can see some ideas for a solution to this problem, because > you can clearly identify all archetypes under the new revisioning > rules vs those that are not. > Most importantly, archetypes under the proposed revisioning scheme > will have a namespace whereas the old ones don't. ah, you got there before me ;-) - thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/4878baf3/attachment.html>
