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. 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. In ADL 1.5. two archetypes with two different namespaces are two completely different archetypes. The same logic could just be used in ADL1.4, even if we can only express the namespace as part of the other_details section at present. Also, they would have the complete revision number (in other_details) that gives you another indicator as well as the development lifecycle in the archetype. So when you want to upgrade your system to replace an archetype that was a draft archetype with a v1 extension with a freshly published v1 archetype with the proposed revisioning rules, you can do this pretty safely by considering the namespace. It then is just like any other incompatible change to an archetype that would cause a replacement of the archetype - the only difference being that the namespace is changed, not the version number in this case. As I said I believe that this is a problem regardless of v0 or not and that it certainly is a problem of some sort for about every vendor. Therefore, I think it deserves a thorough discussion in a separate thread. Could you start this thread if you agree with me that this is a general problem rather than a v0 or v1 problem? Cheers Sebastian On 01.10.2014 15:35, Sebastian Iancu wrote: > Dear all, > > I'm surprise to see such a low analysis of the impact of changing v1 > to v0 of the existing CKM archetypes. > Even though they are not 'published', or are in logical 'draft' mode, > they were conformant to openEHR standards for at least past 5 years or > so. Some of them are used already in production environments for more > than 2-3 years (at least in our case). > Changing them now on CKM will break logical binding with already > existing production data. This cost has to be eventually supported by > industry implementers, and I can assure you this is not trivial, and > it is giving the impression that openEHR standard is not > reliable/stable enough. > > Basically the proposal is to rename existing CKM archetypes (published > or not) in contradiction with what the current openEHR specifications > is stating right now, which is not right. > > Other than this, I personally think that is nice to have v0 for > 'drafts', and v1 for stable-published; it might be a better indication > about a state of an archetype. > So my suggestion is to keep existing CKM archetypes the way they are > and only apply the new 'rule' for archetypes created from now one. > Published archetypes from the sprint can become v2 (or 3, 4 etc) > depends on the need (see specifications). > > Sebastian > Code24 > > > > > > On 10/1/2014 2:57 PM, Thomas Beale wrote: >> On 01/10/2014 13:31, Sebastian Garde wrote: >>> >> >>>> It seems to me a no-brainer that we should support v0, because it's >>>> the clearest possible sign I can think of, that everyone already >>>> recognises, that indicates an artefact to be in early >>>> chaotic/uncontrolled development. So v0 should be the start version >>>> for any archetypes created new on someone's own machine, or any >>>> similar location. >>>> >>> Supporting it as part of the specs for uncontrolled/chaotic >>> development is one thing and I agree. >>> But what we are looking at here is that all CKM archetypes would >>> have a v0 extension until they are first published (as v.1.0.0). >>> Existing pre-publication CKM archetypes would be converted to have a >>> v0 extension (either as a batch or one-by-one when each one is >>> updated the next time) >> >> that sounds right to me - is it a problem? > > >> >>> >>>> * I think that the openEHR.org CKM archetypes identified for the >>>> industry sprint should stay at v1.x, and others that are of >>>> unknown quality should go to v0, which finally establishes what >>>> is clinically trustworthy and what is not. >>>> >>> That's not really an option unless you want to make this migration >>> even more difficult. >>> What you are suggesting requires two different sets of rules and >>> someone needing to deciding which stays at v1 and which is converted >>> to v0. >>> I don't think it makes sense - either we use v0 to indicate >>> pre-publication archetypes or we don't. >> >> I would have thought that individual archetypes can have their >> version modified? I don't think the world minds if there is a period >> of a few months during the industry sprint when the rules are >> technical being broken. Once it's done, there will be 70+ archetypes >> with v1.x, and the rest with v0.x, and that will correctly represent >> the situation of the archetypes in CKM. >> >> Then for every mirroring, copy, and reuse of what's in openEHR.org >> CKM, there is no need to educate anyone on anything - it's obvious >> what the situation is. So we are only talking about a limited period >> of time where the rules are being broken (as they are right now in >> fact ;-) >> >>>> >>>> * I don't see the problem with v0 references in templates, since >>>> it's the same problem between any major version. An archetype >>>> xxxx.v0.x can't be assumed to be compatible with xxxx.v1.y - as >>>> for other major versions, we treat them technically as >>>> different archetypes. So either the template reference is v* >>>> (any major version you like) or it isn't, in which case it >>>> points to a known major version - v0, v1, v2 or other. >>>> o we should assume that future tools will make it easy to >>>> change these template references - it won't be difficult to do. >>>> >>> Sure, looking forward to tooling support on it, but realistically at >>> the moment it is a pain that is not needed for the first publication >>> if you go with v1 as a the initial major version. >> >> well I think its a bigger danger, given the level of reuse of CKM >> archetypes, that the version ids wouldn't correct reflect the state >> of the archetypes. We could in theory revert everything that is not >> published to v0 right now, and i guess that is breaking the rules for >> less time. But there are still some dozens of fully reviewed and >> published archetypes that have to retain their v1.x version anyway. >> So I think the only question is to do with the industry sprint >> archetypes. How about doing this: >> >> * mark archetypes that have never been 'published' and are not in >> the industry sprint as v0.5.0 >> * mark the industry sprint archetypes as v1.0.0-unstable >> * leave currently published archetypes on v1.x, i.e. where they are >> today. >> >> If I receive a copy of archetypes marked like that in say the GitHub >> mirror, or through a different CKM, I don't need any further >> education, it's obvious what's going on. >> >> - thomas >> >> >> >> _______________________________________________ >> openEHR-clinical mailing list >> openEHR-clinical at lists.openehr.org >> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org > > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- *Dr. Sebastian Garde* /Dr. sc. hum., Dipl.-Inform. Med, FACHI/ Ocean Informatics Skype: gardeseb -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/68c00eb0/attachment-0001.html>
