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.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 > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
