I like the idea of a warning on the use (or misuse, purpose...) part of the archetype. I also believe that anything thas has been made public needs to have a unique identifier
2011/7/12 Sebastian Garde <sebastian.garde at oceaninformatics.com>: > > > Am 11.07.2011 17:43, schrieb Thomas Beale: > > On 21/06/2011 10:04, Heather Leslie wrote: > > Hi Erik, Thomas, > > > > I think we need to address three issues separately here. The first is the > archetype identification in CKM; the second is use of the draft archetypes > and the third, the apparent lack of progress of archetype publication in the > openEHR CKM. > > > > Archetype identification is ultimately a technical issue and one in which I > normally don?t have an opinion. Clearly it is useful from an implementation > point of view to have unique IDs for each archetype and be able to determine > diffs etc. However, from a non-technical point of view I believe that it is > extremely helpful to clearly delineate between early/alpha/raw models and > the mature ones that have been published, more than just by a ?status? or > icon, although we need these too. > > > > I?m increasingly of the opinion that it will be helpful to have a common > understanding that the first published version of an archetype in CKM is > always known as v1.0, such that if we eventually find we are using v4.x we > (the non-technical) can easily infer that this is a published archetype that > has undergone 3 major updates. This is very valuable to the non-techies who > will be using CKM. Otherwise we run the risk of having a release set that > will contain wildly disparate version numbers and will infer no idea of the > state/maturity of the archetypes > > To be honest, how we version the pre-published, currently known as ?draft? > archetypes doesn?t worry me ? v0.x seems sensible in light of the previous > statements but if you have a better way to approach it, I?m cool with that. > > so I think this is compatible with: > > a v0 rule that says start at v0.n.m, and go to v1.x.y on first 'publication' > a lifecycle set of states whose names we still need to agree on, but could > be something like: > > alpha, beta, published, obsolete, superseded > > the semver.org rules, which would allow versions like v0.0.1 but also > v1.0.4beta > > I will look at updating the current openEHR artefact specification to > reflect this. > > - thomas > > Thomas and all, > > Changing the version number of the archetype just before publication is not > the right thing to do I believe. > > This means you are doing the review process on the old id (v0, v1, v2, etc.) > and this means that we are required to make incompatible changes to the old > already published archetype [unless it is v0 of course], i.e. while it still > has the old archetype id. > This is something to avoid at all costs I believe. > > I agree that it is valuable to know that v1 is the first published version > (and v2 the second, etc), but I question the value of knowing that v1.0.1 > (or is it v.1.1.1 or v1.0.0 ??) is the first published revision. > What if we made a spelling error and we have to correct a just published > archetype to v1.0.2 or something? Immediately it is not only irrelevant to > know that v1.0.1 was the first, but also ugly because everybody can now see > that v1.0.1 was error-prone and never actually used because it was revised > minutes after publication. I can already see the requests to manipulate > revisioning in CKM to get this little change into v1.0.1 without changing > the revision number! > > While I am also keen to see from the version/ revision numbers whether an > archetype is published or not...it does not really work and is one reason > why the DRAFT ids were deprecated in the first place. > I strongly believe that the status is pretty much orthogonal to the > archetype id/revision and that we should not mix this up. > > Also, we already had archetypes in CKM with a big DRAFT in their archetype > id - and this did not prevent anybody from using these anymore or less than > the status of the archetype being "DRAFT". > If people have a need to use them, they will use them if we make them > available - no matter what their version number or status. > I believe this holds true even if the archetype id ends with > VERYEARLYDRAFTDONEVEREVERUSEANYWHEREWEAREJUSTEXPERIMENTING! > And by all means - let them use them! Just let us be clear on our message > that incompatible changes are likely to occur before publication...this can > be better visual indications of the draft state and its consequences in > Archetype Editors, CKM, etc. > It can also be a text in the ADL/XML of the archetype itself. It can be a > disclaimer in the USE part of the archetype for all DRAFT archetypes. > > If you are keen to infer from these numbers whether it has never been > published, why not use v1.0.1 up to v1.0.n for any not yet published > revision. On publishing, it then could be v1.1.0 or v1.1.1 (or so). It is > not quite as clear (but as I said I don't think it makes any difference), > but at least it is not requiring us to make incompatible changes under the > old archetype id for all versions after v0. Or the prepublication revisions > are even called draft: v1.draft.1 up to v1.draft.n and v.1.0.0 or v.1.1.0 > (e.g.) on first publishing. > > In summary: Do anything, but please do not change the archetype id just > before publication. > > Sebastian > > > > _______________________________________________ > openEHR-clinical mailing list > openEHR-clinical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical >
