On 02.10.2014 09:17, Sebastian Iancu wrote: > 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? > While a v0 would certainly be a draft, a v1 is not necessarily stable. v1.0.0 is stable, and so are e.g. 1.0.1 or 1.1.0 - but 1.0.1-unstable or 1.1.0-unstable are not > > * 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. > Of course the will be v2 archetypes - if you break the archetype in a backwardly incompatible way. This is the case now, it just hasn't happened, partly due to editors trying to avoid incompatible changes if not necessary, partly because many changes have been simple [compatible] additions, partly because the better and comprehensive the feedback you got during the pre-publication review rounds reviews and more careful you were when designing the published archetypes, the less you need it and partly because the more important problem has been to get more draft archetypes reviewed and published.
But the current CKM would strongly advise editors to republish a previously published archetype as v2 if there has been an incompatible change. With the revisioning rules in place, CKM will even create it for you automatically if you like when there have been incompatible changes between the currently published revision and the revision that is to be published. > > * > > > * 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? > I think you have a point here against using v0. If we use v0 and still use current 1.4 rules than this would indeed be weird and messy. Essentially, as soon as you start to use these, you will have to acknowledge namespaces at the very least and maybe this should not be a requirement if you just want to continue to work the way you do now. > > * We know CKM content is not perfect, archetype changes are not > fully considered in their version - why should we create even more > mess? > I agree that CKM content is not perfect of course, but all archetype changes follow the current versioning rule that you have to increase the version identifier if there has been a breaking change. This is for published archetypes, drafts are simply unstable. > > Furthermore, for my point of view: > > * you hardly get early adopters if you discourage them to use > 'draft' archetypes > True, I don't think anybody wants to particularly discourage their use, but you have to live with the risk. > > * 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. > I think the bottom line for most of your points here is that we urgently need more published archetypes that stick to the rules and enable semantic interoperability. I think everybody would have liked to see something like the industry sprint happening 5 years or so ago, but I am very glad it is happening now. > 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. I too think that adding them to the next ADL version and not breaking what is currently in use is important. Namespaces and the revision number etc. would only be available in the other_details fields in ADL 1.4. And of course these fields have no formal meaning per se. So I think if we don't use v0, then you could continue to work in the same way as you do currently. You can then decide to start using these fields when you see fit (or not). What I personally don't like is having a mixture between non-published archetypes in CKM, some of which are v1 and other (newly uploaded) ones that are v0. I think this is indicating different levels of maturity for anybody looking at it, even if both types are simply non-published/unstable. Sebastian > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141002/ebbd8c98/attachment-0001.html>
