Hi Thomas Beale, >openEHR-EHR-ADMIN_ENTRY.encounter.v1 => >org.openEHR::openEHR-EHR-ADMIN_ENTRY.encounter.v0.0.1 => >review & changes => org.openEHR::openEHR-EHR-ADMIN_ENTRY.encounter.v1.0.0
Would file name nomenclature be changed? There is no spec for file name of archetype, but archetype ids have been assigned to file names. Whereas, : is not available for file name in Windows OS (and old Mac OS). Shinji 2014-10-02 7:28 GMT+09:00 Thomas Beale <thomas.beale at oceaninformatics.com>: > On 01/10/2014 16:44, 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. > > > but none of the existing CKM archetype ids has a namespace, so the new ids > will be distinguishable from the old. It would be useful to have some real > data on who has used any CKM draft (i.e. 'old') archetypes in real systems > to know is there is in fact a problem here or not. > > Anyway, the renaming should follow the model: > > openEHR-EHR-ADMIN_ENTRY.encounter.v1 => > org.openEHR::openEHR-EHR-ADMIN_ENTRY.encounter.v0.0.1 => review & changes => > org.openEHR::openEHR-EHR-ADMIN_ENTRY.encounter.v1.0.0 > > so there is no way for the first and last versions to get mixed up that I > can see. > > 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. > > > ah, you got there before me ;-) > > - thomas > > > _______________________________________________ > openEHR-clinical mailing list > openEHR-clinical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
