Hi Diego, There will be a v2 very soon. It will be the first of the small number of published archetypes that has had backwardly incompatible changes required.
It is Indirect Oximetry which will go out for further review next week, but we already have had a breaking error identified. Regards Heather -----Original Message----- From: openEHR-technical [mailto:[email protected]] On Behalf Of Diego Bosc? Sent: Thursday, 2 October 2014 5:48 PM To: For openEHR technical discussions Cc: For openEHR clinical discussions Subject: Re: Archetype Naming proposals - do we need V0? I agree with your points. I would say that some of your points are the reasons people is reluctant in adopting openEHR more. It's not all about licenses. It has always puzzled me why there is not a single v2 archetype in CKM after 7 years. 2014-10-02 9:17 GMT+02:00 Sebastian Iancu <sebastian at code24.nl>: > Hi Sebastian G, David M, > > > Thank you for your elaborate answers. > > I can proudly say, years ago, we were one of the early adopters of openEHR. > We've been there (in fact actively participating) when the CAM-hash > was introduced, or when .v1draft was replaced with .v1, or when the > archetype_id versioning policy was polished, or when Thomas started to > work on distributed knowledge management and artefact identification. > I'm not a stranger to the fact that CKM archetypes are changing > without having their version updated, sometimes breaking existing > specifications. I also acknowledge the benefits of the > industry-sprint, and that we need clearing things out in CKM content > for that. Finally, as technician, I'm aware of the impact of using > 'draft'-like artefacts in own software. > > But, I cannot agree with a mass regression to v0: > > What's the point of having this boolean logic where draft=0, stable=1? > Are we never going to have v2? And if yes, would that mean something > (published-on-Mars-aswell, or sprint-2)? The version itself should not > be important (we can have v1 or v87), it matters only in relation with > other versions and a timeline. > There are already released specification about versioning, so why > violate them doing odd regression? > There is no guaranty that all current drafts will be published some > day - in which case we might be stuck with v0, while v1 was already > available up to 2014. Why should we destroy something that already exists and > it works? > We know CKM content is not perfect, archetype changes are not fully > considered in their version - why should we create even more mess? > > Furthermore, for my point of view: > > you hardly get early adopters if you discourage them to use 'draft' > archetypes > an archetype uploaded on CKM is in fact sort-of technically published, > although not domain-published. Breaking it constantly makes it > unusable and lowers the adoption or real-life testing chances. > encouraging vendors or consumers to use their own archetype > repositories (own namespaces) as opposed to a global own (CKM) is a > threat to interoperability, and defies some of the openEHR principles. > > > In conclusion, > I'm not at all against the new versioning identification, discussed > these days (i.e v1.2.3, etc), as long as it is introduced only in/for > upcoming specifications (ADL 1.5, 2.0 whatever) and it is not breaking > existing systems based on RM 1.0.2 and ADL 1.4 archetypes. Keep things > simpler and don't focus too much on only syncing with semver, while > you forget the big picture where these archetypes are actually used > for (namely to describe data). > > Sebastian > Code24 > > > > On 10/1/2014 5:44 PM, 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. > 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. > > 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.opene > hr.org > > > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.open > ehr.org > > > -- > > Dr. Sebastian Garde > Dr. sc. hum., Dipl.-Inform. Med, FACHI Ocean Informatics > > Skype: gardeseb > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.open > ehr.org > > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.open > ehr.org _______________________________________________ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
