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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/893e4adb/attachment.html>
