Archetype Naming proposals - do we need V0?
On 01/10/2014 13:36, Ian McNicoll wrote: > Hi Thomas, > > I agree with all you haver said but would stick to my original > assertion that for *practical' and computable purposes, in terms of > fitness to be used in an operational system and adherance to the > version number rules, v0.0.1 and v1.0.1-unstable are identical. I don't see how that can be. The former is for some uncontrolled archetype from an unmanaged external location, and the latter is a post v1.0.0 archetype in development, after having been published as v1.0.0 > > Both, when published will end up as V1.0.0, both are unstable. in entirely different ways. the v0 isn't technically under development in CKM until you start working on it. That might be 6 months after upload. > > I can see the human argument for differentiating a truly feral > archetype from one in a controlled repository but am not convinced > that this outweighs the hassle of supporting V0 in ADL1.4. in ADL 1.4? I don't know, but the identification and versioning rules for CKM , even while it still has 1.4 archetypes, needs to be of the 1.5 variety. > > When we move to ADL1.5 tooling and downstream systems will need to be > changed in any case, so perhaps that is the point to formally > introduce V0? I thought the whole point was to introduce new style versioning (namespaces, 3 part version ids, extra meta-data) into CKM now? If so, why would we not include 'v0', which is part of that spec? - thomas -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/2a075ce3/attachment-0001.html>
Archetype Naming proposals - do we need V0?
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 -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/4878baf3/attachment.html>
Archetype Naming proposals - do we need V0?
Hi Ian. I have read once SemVer, but it is still confusing about suffix. especially "alpha.11 > alpha.beta > beta.1" sequence. This needs tricky grammar rule to parse. Hi Sebastian, I think revision history should be exclusive, even it is unstable version. Regards, Shinji 2014-10-01 21:26 GMT+09:00 Ian McNicoll : > Hi Shinji, > > Can I suggest you read the semver.org specifications? Semver is now used > pretty widely in systems and tooling (including the nodeJS Package Manager > NPM). We have taken the - suffix directly from those specifications and in > other respcts we are now following semver exactly so there should be open > source parsers out there that can be used. > > > Semver exists because we have to treat semantic specifications differently > from normal software builds. In normal software alpha, beta, pre-release and > indeed the numbering chosen do not need to have any computable significance. > Windows 9 is only called Windows 9 for marketing reasons ,not because it > represents a breaking change. My recent Yosemite Beta 3-> Beta 4 update may > make all sorts of breaking changes but is still a Beta and appears to be > only a build different from the Developer Pre-release Yosemite candidate. > > When we are dealing with Semantic artefacts such as APIs or archetypes, the > numbering scheme and suffixes have very specific meanings and rules, to do > with backward compatibility. > > The -suffix is necessary to make it very clear that this is a pre-release > artefact and that the normal versioning rules do not apply. What comes after > the suffix does not really matter and > > The prime responsibility we have as archetype authors is to make sure that > developers know whether they are working with a stable, published archetype > which has followed the versioning rules, or an unstable archetype where > those rules are temporarily suspended. > > It is impossible to do this clearly with a numbering schema alone which is > why the - suffix is well-established in SemVer and the tools which use it. > > In normal circumstances unstable archetypes would never be used in > production systems. > > Ian > > > On 1 October 2014 13:04, Shinji KOBAYASHI wrote: >> >> Hi Ian, >> >> I prefer V0, because it would be easier to adopt for other developers >> who do not know openEHR well. >> For parser implementation, 1.0.0-unstable is not a good design, >> because it is not clear that which is the later release amongs, >> unstable, testing, pre-release, release-candidate, draft, etc... >> I would suggest 0.9.9 instead of 1.0.0-unstable. We can revise the >> revision 0.9.9 after it released, to 0.9.9.9. or 0.9.9.99. >> >> Shinji >> >> 2014-10-01 19:23 GMT+09:00 Ian McNicoll : >> > >> > Hi all, >> > >> > Apologies for cross-posting in both clinical and technical but this does >> > neatly cross that divide. >> > >> > We are getting close in CKM to implementing the ADL1.5 archetype naming >> > /versioning rules proposed at >> > >> > >> > http://www.openehr.org/wiki/display/ADL/Knowledge+Artefact+Identification >> > >> > mostly by adding the metadata to the ADL other_details section, which >> > means >> > we can carry the information in ADL 1.4 archetypes without disturbing >> > current systems. >> > >> > These latest proposals are now very much in line with the de-facto >> > standard >> > SemVer 2.0 see http://semver.org which allows >> > >> > major revision >> > minor revision >> > patch >> > build >> > >> > but one of the questions which remains controversial is whether to >> > support a >> > major revision of V0 (as allowed in SemVer). >> > >> > In Semver, V0 is allowed for very immature ?first draft? semantic >> > artefacts/APIs prior to initial release but SemVer allows for any >> > revision >> > to appended with a pre-release modifier >> > >> > e.g. v2.0.0-alpha or v1.0.0-unstable >> > >> > This is recognised as meaning that the artefact is unstable and the >> > version >> > numbering cannot be relied on e.g to assert backward compatibility. >> > >> > In that sense v0.0.0 and v1.0.0-unstable are identical in terms of their >> > ?stability? and lack of commitment to the versioning rules. >> > >> > So the question for us in the openEHR world is whether tooling should >> > support v0.0.0, or simply use v1.0.0-unstable >> > >> > V0 Advantages >> > >> > 1. The archetype is clearly marked as immature >> > 2. Full compliance with SemVer >> > 3. Supported in current test build of CKM >> > >> > V0 Disadvantages >> > >> > 1. Tooling e.g Archetype Editor (actually ADL Parser) needs to change to >> > support V0 >> > 2. Add another layer of complexity to the archetype naming/versioning >> > rules >> > 3. Question arises of whether / if to convert current draft V1 CKM >> > archetypes to V0 with overhead of explanation to current users. >> > 4. Adds complexity where V0 archetypes are being used within templates, >> > when >> > the archetype is published and needs to be updated to V1 within these >> > templates. >> > >> > >> >
Archetype Naming proposals - do we need V0?
Hi Ian, I prefer V0, because it would be easier to adopt for other developers who do not know openEHR well. For parser implementation, 1.0.0-unstable is not a good design, because it is not clear that which is the later release amongs, unstable, testing, pre-release, release-candidate, draft, etc... I would suggest 0.9.9 instead of 1.0.0-unstable. We can revise the revision 0.9.9 after it released, to 0.9.9.9. or 0.9.9.99. Shinji 2014-10-01 19:23 GMT+09:00 Ian McNicoll : > > Hi all, > > Apologies for cross-posting in both clinical and technical but this does > neatly cross that divide. > > We are getting close in CKM to implementing the ADL1.5 archetype naming > /versioning rules proposed at > > http://www.openehr.org/wiki/display/ADL/Knowledge+Artefact+Identification > > mostly by adding the metadata to the ADL other_details section, which means > we can carry the information in ADL 1.4 archetypes without disturbing > current systems. > > These latest proposals are now very much in line with the de-facto standard > SemVer 2.0 see http://semver.org which allows > > major revision > minor revision > patch > build > > but one of the questions which remains controversial is whether to support a > major revision of V0 (as allowed in SemVer). > > In Semver, V0 is allowed for very immature ?first draft? semantic > artefacts/APIs prior to initial release but SemVer allows for any revision > to appended with a pre-release modifier > > e.g. v2.0.0-alpha or v1.0.0-unstable > > This is recognised as meaning that the artefact is unstable and the version > numbering cannot be relied on e.g to assert backward compatibility. > > In that sense v0.0.0 and v1.0.0-unstable are identical in terms of their > ?stability? and lack of commitment to the versioning rules. > > So the question for us in the openEHR world is whether tooling should > support v0.0.0, or simply use v1.0.0-unstable > > V0 Advantages > > 1. The archetype is clearly marked as immature > 2. Full compliance with SemVer > 3. Supported in current test build of CKM > > V0 Disadvantages > > 1. Tooling e.g Archetype Editor (actually ADL Parser) needs to change to > support V0 > 2. Add another layer of complexity to the archetype naming/versioning rules > 3. Question arises of whether / if to convert current draft V1 CKM > archetypes to V0 with overhead of explanation to current users. > 4. Adds complexity where V0 archetypes are being used within templates, when > the archetype is published and needs to be updated to V1 within these > templates. > > > V1- Advantages > > 1. Compliant with SemVer > 2. Does not need any changes to Archetype Editor. > 3. Easier transition between draft and publication states when used within > templates i.e does not need V0->v1 change > > > V1- Disadvantages > 1. Does not so clearly differentiate ?first draft? archetype from others > > > Before a final decision is made, we are interested in feedback from the > community on whether V0 should be implemented in CKM and other openEHR > tools, although in practice V1- will do an identical job in terms of version > number governance. > > Regards, > > Ian McNicoll > Heather Leslie > Sebastian Garde > Thomas Beale > > > > ___ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Archetype Naming proposals - do we need V0?
lease but SemVer allows for any >>>>>> revision >>>>>> to appended with a pre-release modifier >>>>>> >>>>>> e.g. v2.0.0-alpha or v1.0.0-unstable >>>>>> >>>>>> This is recognised as meaning that the artefact is unstable and the >>>>>> version >>>>>> numbering cannot be relied on e.g to assert backward compatibility. >>>>>> >>>>>> In that sense v0.0.0 and v1.0.0-unstable are identical in terms of >>>>>> their >>>>>> ?stability? and lack of commitment to the versioning rules. >>>>>> >>>>>> So the question for us in the openEHR world is whether tooling should >>>>>> support v0.0.0, or simply use v1.0.0-unstable >>>>>> >>>>>> V0 Advantages >>>>>> >>>>>> 1. The archetype is clearly marked as immature >>>>>> 2. Full compliance with SemVer >>>>>> 3. Supported in current test build of CKM >>>>>> >>>>>> V0 Disadvantages >>>>>> >>>>>> 1. Tooling e.g Archetype Editor (actually ADL Parser) needs to change >>>>>> to >>>>>> support V0 >>>>>> 2. Add another layer of complexity to the archetype naming/versioning >>>>>> rules >>>>>> 3. Question arises of whether / if to convert current draft V1 CKM >>>>>> archetypes to V0 with overhead of explanation to current users. >>>>>> 4. Adds complexity where V0 archetypes are being used within >>>>>> templates, >>>>>> when >>>>>> the archetype is published and needs to be updated to V1 within these >>>>>> templates. >>>>>> >>>>>> >>>>>> V1- Advantages >>>>>> >>>>>> 1. Compliant with SemVer >>>>>> 2. Does not need any changes to Archetype Editor. >>>>>> 3. Easier transition between draft and publication states when used >>>>>> within >>>>>> templates i.e does not need V0->v1 change >>>>>> >>>>>> >>>>>> V1- Disadvantages >>>>>> 1. Does not so clearly differentiate ?first draft? archetype from >>>>>> others >>>>>> >>>>>> >>>>>> Before a final decision is made, we are interested in feedback from >>>>>> the >>>>>> community on whether V0 should be implemented in CKM and other >>>>>> openEHR >>>>>> tools, although in practice V1- will do an identical job in terms of >>>>>> version >>>>>> number governance. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Ian McNicoll >>>>>> Heather Leslie >>>>>> Sebastian Garde >>>>>> Thomas Beale >>>>>> >>>>>> >>>>>> >>>>>> ___ >>>>>> 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 >>>> >>>> >>>> >>>> -- >>>> Dr Ian McNicoll >>>> office / fax +44(0)141 560 4657 >>>> mobile +44 (0)775 209 7859 >>>> skype ianmcnicoll >>>> ian at freshehr.com >>>> >>>> Clinical modelling consultant freshEHR >>>> Director openEHR Foundation >>>> Honorary Senior Research Associate, CHIME, UCL >>>> BCS Primary Health Care www.phcsg.org >>>> >>>> ___ >>>> openEHR-clinical mailing list >>>> openEHR-clinical at lists.openehr.org >>>> >>>> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org >>> ___ >>> openEHR-clinical mailing list >>> openEHR-clinical at lists.openehr.org >>> >>> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org >> >> >> >> -- >> Dr Ian McNicoll >> office / fax +44(0)141 560 4657 >> mobile +44 (0)775 209 7859 >> skype ianmcnicoll >> ian at freshehr.com >> >> Clinical modelling consultant freshEHR >> Director openEHR Foundation >> Honorary Senior Research Associate, CHIME, UCL >> BCS Primary Health Care www.phcsg.org >> >> ___ >> 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 -- *Dr. Sebastian Garde* /Dr. sc. hum., Dipl.-Inform. Med, FACHI/ Ocean Informatics Skype: gardeseb -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/72ce209b/attachment-0001.html>
Archetype Naming proposals - do we need V0?
etypes 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 >>>> .v0.x can't be assumed to be compatible with .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 > > > > ___ > 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 -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/68c00eb0/attachment-0001.html>
Archetype Naming proposals - do we need V0?
relied on e.g to assert backward compatibility. > > In that sense v0.0.0 and v1.0.0-unstable are identical in terms of > their > ?stability? and lack of commitment to the versioning rules. > > So the question for us in the openEHR world is whether tooling should > support v0.0.0, or simply use v1.0.0-unstable > > V0 Advantages > > 1. The archetype is clearly marked as immature > 2. Full compliance with SemVer > 3. Supported in current test build of CKM > > V0 Disadvantages > > 1. Tooling e.g Archetype Editor (actually ADL Parser) needs to change > to > support V0 > 2. Add another layer of complexity to the archetype naming/versioning > rules > 3. Question arises of whether / if to convert current draft V1 CKM > archetypes to V0 with overhead of explanation to current users. > 4. Adds complexity where V0 archetypes are being used within > templates, > when > the archetype is published and needs to be updated to V1 within these > templates. > > > V1- Advantages > > 1. Compliant with SemVer > 2. Does not need any changes to Archetype Editor. > 3. Easier transition between draft and publication states when used > within > templates i.e does not need V0->v1 change > > > V1- Disadvantages > 1. Does not so clearly differentiate ?first draft? archetype from > others > > > Before a final decision is made, we are interested in feedback from > the > community on whether V0 should be implemented in CKM and other > openEHR > tools, although in practice V1- will do an identical job in terms of > version > number governance. > > Regards, > > Ian McNicoll > Heather Leslie > Sebastian Garde > Thomas Beale > > > > ___ > openEHR-technical mailing listopenEHR-technical at lists.openehr.org > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > > ___ > openEHR-technical mailing listopenEHR-technical at lists.openehr.org > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > > > > > -- > Dr Ian McNicoll > office / fax +44(0)141 560 4657 > mobile +44 (0)775 209 7859 > skype ianmcnicollian at freshehr.com > > Clinical modelling consultant freshEHR > Director openEHR Foundation > Honorary Senior Research Associate, CHIME, UCL > BCS Primary Health Care www.phcsg.org > > ___ > openEHR-clinical mailing listopenEHR-clinical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org > > ___ > openEHR-clinical mailing listopenEHR-clinical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org > > > > > -- > Dr Ian McNicoll > office / fax +44(0)141 560 4657 > mobile +44 (0)775 209 7859 > skype ianmcnicollian at freshehr.com > > Clinical modelling consultant freshEHR > Director openEHR Foundation > Honorary Senior Research Associate, CHIME, UCL > BCS Primary Health Care www.phcsg.org > > ___ > openEHR-technical mailing listopenEHR-technical at > lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > > ___ > openEHR-technical mailing listopenEHR-technical at > lists.openehr.orghttp://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 > -- Dr Ian McNicoll office / fax +44(0)141 560 4657 mobile +44 (0)775 209 7859 skype ianmcnicoll ian at freshehr.com Clinical modelling consultant freshEHR Director openEHR Foundation Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care www.phcsg.org -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/5f95892c/attachment-0001.html>
Licensing of specs and artifacts
Hi everyone, In light of the recent re-licensing of FHIR<http://www.healthintersections.com.au/?p=2248> using the Creative Commons CC0 Public Domain Dedication as well as the discussion about licensing at the 2014 openEHR Roadmap Meeting<http://www.openehr.org/wiki/display/oecom/September+2014+Roadmap+Meeting> in Lillestr?m on September 16 and 17, I'd like to restart the discussion on licensing of openEHR specifications and artefacts (mainly archetypes, but also potentially templates and terminology sets). As of now, the specifications are licensed using the Creative Commons Attribution No-Derivatives<http://creativecommons.org/licenses/by-nd/3.0/> (CC-B-ND) license, while the Creative Commons Attribution Share-Alike<http://creativecommons.org/licenses/by-sa/3.0/> (CC-BY-SA) is used for artefacts. Several issues have been raised about this choice of licences. Feel free to add to this list, I'm bound to have forgot some issues: CC-BY-ND (for specs): ? Theoretically, a hostile takeover of the openEHR Foundation might leave the openEHR specs dead, as with the CC-BY-ND only the copyright holder (the Foundation) has the rights to modify them. A forkable license like for instance CC-BY-SA would solve this issue. Global registering of the openEHR trademark would keep any derivates to be branded as "openEHR". CC-BY-SA (for artefacts): ? Commercial implementers might avoid using CC-BY-SA artefacts because the license requires any published modifications of the work to be licensed using the same license. This might lead implementers to believe the license would require them to license their entire software product as CC-BY-SA. There are several examples of CC-BY-SA works being used in copyrighted works, such as Wikipedia articles being used in newspapers, but this is probably reliant on a benign licensor, which any normal commercial company can't rely 100% on. The way I see it, this problem could be solved in one of two ways: o Use the CC-BY license, which retains the attribution clause, but doesn't require any derivative works to use the same license. This has the disadvantage of enabling proprietary tweaking of archetypes, which could potentially ruin interoperability. o Retain the CC-BY-SA license, but add an explicit clause that allows all implementers to use artefacts in closed-source, proprietary products with any license they like. Artefacts published by themselves, as standalone archetypes, templates or terminology sets would still be bound by the ShareAlike clause. This is supported by Creative Commons via the CC+<https://wiki.creativecommons.org/CCPlus> protocol. I realise these issues will ultimately be decided by the board of the openEHR Foundation, but if the community can come to some kind of consensus on this issue I would hope it'd send them a strong signal. Kind regards, Silje Ljosland Bakke Coordinator, National Editorial Board for Archetypes, National ICT Norway Adviser, R&D dept, E-health section, Bergen Hospital Trust Tel. +47 40203298 -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/5e2d6c81/attachment-0001.html>
Archetype Naming proposals - do we need V0?
2014-10-01 15:35 GMT+02:00 Sebastian Iancu : > 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. > > Sebastian, Although you are for sure right in your worries, that doesn't mean that current archetypes managed in CKM are safer. For many years most of the current v1 archetypes in CKM where in draft and that meant that they have been changing without changing their id. You can protect your systems if you check archetype correspondences not only by the archetype id but using something else such as their hash code. And in that case, changing to v0 should not mean any difference or additional problem. David -- David Moner Cano Grupo de Inform?tica Biom?dica - IBIME Instituto ITACA http://www.ibime.upv.es http://www.linkedin.com/in/davidmoner Universidad Polit?cnica de Valencia (UPV) Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta Valencia - 46022 (Espa?a) -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/fc487bf9/attachment.html>
Archetype Naming proposals - do we need V0?
mmunity on whether V0 should be implemented in CKM and other openEHR >>> tools, although in practice V1- will do an identical job in terms of version >>> number governance. >>> >>> Regards, >>> >>> Ian McNicoll >>> Heather Leslie >>> Sebastian Garde >>> Thomas Beale >>> >>> >>> >>> ___ >>> 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 -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/63248d6e/attachment.html>
Archetype Naming proposals - do we need V0?
> 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. > As above, then you are applying two different set of rules for migration, depending on whether the archetype is in the industry sprint or not. Apart from the additional complexity I tried to explain, what is the point? The only point I can see is that you want to identify industry sprint archetypes: I think they are all part of one project now and you can easily get them from there. > 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. Well, I for one, would not understand without your explanation that the difference between 0.5.0 and 1.0.0-unstable is that the one is in industry sprint and the other isn't. There are more logical ways to me to find this out (just look at the CKM project). Sebastian -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/fa01a433/attachment-0001.html>
Archetype Naming proposals - do we need V0?
f > 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>
Archetype Naming proposals - do we need V0?
; >>> ?stability? and lack of commitment to the versioning rules. > >>> > >>> So the question for us in the openEHR world is whether tooling should > >>> support v0.0.0, or simply use v1.0.0-unstable > >>> > >>> V0 Advantages > >>> > >>> 1. The archetype is clearly marked as immature > >>> 2. Full compliance with SemVer > >>> 3. Supported in current test build of CKM > >>> > >>> V0 Disadvantages > >>> > >>> 1. Tooling e.g Archetype Editor (actually ADL Parser) needs to change > to > >>> support V0 > >>> 2. Add another layer of complexity to the archetype naming/versioning > rules > >>> 3. Question arises of whether / if to convert current draft V1 CKM > >>> archetypes to V0 with overhead of explanation to current users. > >>> 4. Adds complexity where V0 archetypes are being used within > templates, when > >>> the archetype is published and needs to be updated to V1 within these > >>> templates. > >>> > >>> > >>> V1- Advantages > >>> > >>> 1. Compliant with SemVer > >>> 2. Does not need any changes to Archetype Editor. > >>> 3. Easier transition between draft and publication states when used > within > >>> templates i.e does not need V0->v1 change > >>> > >>> > >>> V1- Disadvantages > >>> 1. Does not so clearly differentiate ?first draft? archetype from > others > >>> > >>> > >>> Before a final decision is made, we are interested in feedback from the > >>> community on whether V0 should be implemented in CKM and other openEHR > >>> tools, although in practice V1- will do an identical job in terms of > version > >>> number governance. > >>> > >>> Regards, > >>> > >>> Ian McNicoll > >>> Heather Leslie > >>> Sebastian Garde > >>> Thomas Beale > >>> > >>> > >>> > >>> ___ > >>> 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 > -- Dr Ian McNicoll office / fax +44(0)141 560 4657 mobile +44 (0)775 209 7859 skype ianmcnicoll ian at freshehr.com Clinical modelling consultant freshEHR Director openEHR Foundation Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care www.phcsg.org -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/3ec26155/attachment.html>
Archetype Naming proposals - do we need V0?
current users. >>> 4. Adds complexity where V0 archetypes are being used within templates, >>> when >>> the archetype is published and needs to be updated to V1 within these >>> templates. >>> >>> >>> V1- Advantages >>> >>> 1. Compliant with SemVer >>> 2. Does not need any changes to Archetype Editor. >>> 3. Easier transition between draft and publication states when used >>> within >>> templates i.e does not need V0->v1 change >>> >>> >>> V1- Disadvantages >>> 1. Does not so clearly differentiate ?first draft? archetype from others >>> >>> >>> Before a final decision is made, we are interested in feedback from the >>> community on whether V0 should be implemented in CKM and other openEHR >>> tools, although in practice V1- will do an identical job in terms of >>> version >>> number governance. >>> >>> Regards, >>> >>> Ian McNicoll >>> Heather Leslie >>> Sebastian Garde >>> Thomas Beale >>> >>> >>> >>> ___ >>> openEHR-technical mailing list >>> openEHR-technical at lists.openehr.org <mailto: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 <mailto: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-clinical mailing list > openEHR-clinical at lists.openehr.org > <mailto:openEHR-clinical at lists.openehr.org> > > http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org > > > > > -- > Dr Ian McNicoll > office / fax +44(0)141 560 4657 > mobile +44 (0)775 209 7859 > skype ianmcnicoll > ian at freshehr.com <mailto:ian at freshehr.com> > > Clinical modelling consultant freshEHR > Director openEHR Foundation > Honorary Senior Research Associate, CHIME, UCL > BCS Primary Health Care www.phcsg.org <http://www.phcsg.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 -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/85a8ed93/attachment.html>
Archetype Naming proposals - do we need V0?
eased, to 0.9.9.9. or 0.9.9.99. > >> > >> Shinji > >> > >> 2014-10-01 19:23 GMT+09:00 Ian McNicoll : > >> > > >> > Hi all, > >> > > >> > Apologies for cross-posting in both clinical and technical but this > does > >> > neatly cross that divide. > >> > > >> > We are getting close in CKM to implementing the ADL1.5 archetype > naming > >> > /versioning rules proposed at > >> > > >> > > >> > > http://www.openehr.org/wiki/display/ADL/Knowledge+Artefact+Identification > >> > > >> > mostly by adding the metadata to the ADL other_details section, which > >> > means > >> > we can carry the information in ADL 1.4 archetypes without disturbing > >> > current systems. > >> > > >> > These latest proposals are now very much in line with the de-facto > >> > standard > >> > SemVer 2.0 see http://semver.org which allows > >> > > >> > major revision > >> > minor revision > >> > patch > >> > build > >> > > >> > but one of the questions which remains controversial is whether to > >> > support a > >> > major revision of V0 (as allowed in SemVer). > >> > > >> > In Semver, V0 is allowed for very immature ?first draft? semantic > >> > artefacts/APIs prior to initial release but SemVer allows for any > >> > revision > >> > to appended with a pre-release modifier > >> > > >> > e.g. v2.0.0-alpha or v1.0.0-unstable > >> > > >> > This is recognised as meaning that the artefact is unstable and the > >> > version > >> > numbering cannot be relied on e.g to assert backward compatibility. > >> > > >> > In that sense v0.0.0 and v1.0.0-unstable are identical in terms of > their > >> > ?stability? and lack of commitment to the versioning rules. > >> > > >> > So the question for us in the openEHR world is whether tooling should > >> > support v0.0.0, or simply use v1.0.0-unstable > >> > > >> > V0 Advantages > >> > > >> > 1. The archetype is clearly marked as immature > >> > 2. Full compliance with SemVer > >> > 3. Supported in current test build of CKM > >> > > >> > V0 Disadvantages > >> > > >> > 1. Tooling e.g Archetype Editor (actually ADL Parser) needs to change > to > >> > support V0 > >> > 2. Add another layer of complexity to the archetype naming/versioning > >> > rules > >> > 3. Question arises of whether / if to convert current draft V1 CKM > >> > archetypes to V0 with overhead of explanation to current users. > >> > 4. Adds complexity where V0 archetypes are being used within > templates, > >> > when > >> > the archetype is published and needs to be updated to V1 within these > >> > templates. > >> > > >> > > >> > V1- Advantages > >> > > >> > 1. Compliant with SemVer > >> > 2. Does not need any changes to Archetype Editor. > >> > 3. Easier transition between draft and publication states when used > >> > within > >> > templates i.e does not need V0->v1 change > >> > > >> > > >> > V1- Disadvantages > >> > 1. Does not so clearly differentiate ?first draft? archetype from > others > >> > > >> > > >> > Before a final decision is made, we are interested in feedback from > the > >> > community on whether V0 should be implemented in CKM and other openEHR > >> > tools, although in practice V1- will do an identical job in terms of > >> > version > >> > number governance. > >> > > >> > Regards, > >> > > >> > Ian McNicoll > >> > Heather Leslie > >> > Sebastian Garde > >> > Thomas Beale > >> > > >> > > >> > > >> > ___ > >> > 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 > > > > > > > > > > -- > > Dr Ian McNicoll > > office / fax +44(0)141 560 4657 > > mobile +44 (0)775 209 7859 > > skype ianmcnicoll > > ian at freshehr.com > > > > Clinical modelling consultant freshEHR > > Director openEHR Foundation > > Honorary Senior Research Associate, CHIME, UCL > > BCS Primary Health Care www.phcsg.org > > > > ___ > > openEHR-clinical mailing list > > openEHR-clinical at lists.openehr.org > > > http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org > > ___ > openEHR-clinical mailing list > openEHR-clinical at lists.openehr.org > > http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org > -- Dr Ian McNicoll office / fax +44(0)141 560 4657 mobile +44 (0)775 209 7859 skype ianmcnicoll ian at freshehr.com Clinical modelling consultant freshEHR Director openEHR Foundation Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care www.phcsg.org -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/ee63c85f/attachment-0001.html>
Archetype Naming proposals - do we need V0?
Hi Diego,
On 01.10.2014 12:54, Diego Bosc? wrote:
> I tested v0 with LinkEHR editor and works just fine.
That's great, although in this case I think you are actually being too
lenient if you strickly stick to the current spec which defines a
V_IDENTIFIER as
[a-zA-Z][a-zA-Z0-9_]+(-[a-zA-Z][a-zA-Z0-9_]+){2}\.[a-zA-Z][a-zA-Z0-9_]+(-[a-
zA-Z][a-zA-Z0-9_]+)*\.v*[1-9]*[0-9]*
> v0 is also fully compliant with SemVer, which means that in theory
> archetype identifiers won't need to be changed when we move to ADL1.5
> (going with v1-unestable will need another change in the future)
v1.0.0-unstable is also fully compliant with SemVer - I don't understand
why this would require more changes in the future that v0 doesn't need?
Sebastian
>
>
> 2014-10-01 12:23 GMT+02:00 Ian McNicoll :
>> Hi all,
>>
>> Apologies for cross-posting in both clinical and technical but this does
>> neatly cross that divide.
>>
>> We are getting close in CKM to implementing the ADL1.5 archetype naming
>> /versioning rules proposed at
>>
>> http://www.openehr.org/wiki/display/ADL/Knowledge+Artefact+Identification
>>
>> mostly by adding the metadata to the ADL other_details section, which means
>> we can carry the information in ADL 1.4 archetypes without disturbing
>> current systems.
>>
>> These latest proposals are now very much in line with the de-facto standard
>> SemVer 2.0 see http://semver.org which allows
>>
>> major revision
>> minor revision
>> patch
>> build
>>
>> but one of the questions which remains controversial is whether to support a
>> major revision of V0 (as allowed in SemVer).
>>
>> In Semver, V0 is allowed for very immature ?first draft? semantic
>> artefacts/APIs prior to initial release but SemVer allows for any revision
>> to appended with a pre-release modifier
>>
>> e.g. v2.0.0-alpha or v1.0.0-unstable
>>
>> This is recognised as meaning that the artefact is unstable and the version
>> numbering cannot be relied on e.g to assert backward compatibility.
>>
>> In that sense v0.0.0 and v1.0.0-unstable are identical in terms of their
>> ?stability? and lack of commitment to the versioning rules.
>>
>> So the question for us in the openEHR world is whether tooling should
>> support v0.0.0, or simply use v1.0.0-unstable
>>
>> V0 Advantages
>>
>> 1. The archetype is clearly marked as immature
>> 2. Full compliance with SemVer
>> 3. Supported in current test build of CKM
>>
>> V0 Disadvantages
>>
>> 1. Tooling e.g Archetype Editor (actually ADL Parser) needs to change to
>> support V0
>> 2. Add another layer of complexity to the archetype naming/versioning rules
>> 3. Question arises of whether / if to convert current draft V1 CKM
>> archetypes to V0 with overhead of explanation to current users.
>> 4. Adds complexity where V0 archetypes are being used within templates, when
>> the archetype is published and needs to be updated to V1 within these
>> templates.
>>
>>
>> V1- Advantages
>>
>> 1. Compliant with SemVer
>> 2. Does not need any changes to Archetype Editor.
>> 3. Easier transition between draft and publication states when used within
>> templates i.e does not need V0->v1 change
>>
>>
>> V1- Disadvantages
>> 1. Does not so clearly differentiate ?first draft? archetype from others
>>
>>
>> Before a final decision is made, we are interested in feedback from the
>> community on whether V0 should be implemented in CKM and other openEHR
>> tools, although in practice V1- will do an identical job in terms of version
>> number governance.
>>
>> Regards,
>>
>> Ian McNicoll
>> Heather Leslie
>> Sebastian Garde
>> Thomas Beale
>>
>>
>>
>> ___
>> 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
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/b942d273/attachment.html>
Archetype Naming proposals - do we need V0?
On 01.10.2014 14:04, Shinji KOBAYASHI wrote: > Hi Ian, > > I prefer V0, because it would be easier to adopt for other developers > who do not know openEHR well. > For parser implementation, 1.0.0-unstable is not a good design, > because it is not clear that which is the later release amongs, > unstable, testing, pre-release, release-candidate, draft, etc... Actually, this is clearly defined by SemVer, see rule 11: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0. But I don't think we would usually want to do this at all for unstable archetypes. They are just unstable, no guarantee whatsoever. If you want to have a specific one, you can always use the unique build id for that. Sebastian > I would suggest 0.9.9 instead of 1.0.0-unstable. We can revise the > revision 0.9.9 after it released, to 0.9.9.9. or 0.9.9.99. > > Shinji > > 2014-10-01 19:23 GMT+09:00 Ian McNicoll : >> Hi all, >> >> Apologies for cross-posting in both clinical and technical but this does >> neatly cross that divide. >> >> We are getting close in CKM to implementing the ADL1.5 archetype naming >> /versioning rules proposed at >> >> http://www.openehr.org/wiki/display/ADL/Knowledge+Artefact+Identification >> >> mostly by adding the metadata to the ADL other_details section, which means >> we can carry the information in ADL 1.4 archetypes without disturbing >> current systems. >> >> These latest proposals are now very much in line with the de-facto standard >> SemVer 2.0 see http://semver.org which allows >> >> major revision >> minor revision >> patch >> build >> >> but one of the questions which remains controversial is whether to support a >> major revision of V0 (as allowed in SemVer). >> >> In Semver, V0 is allowed for very immature ?first draft? semantic >> artefacts/APIs prior to initial release but SemVer allows for any revision >> to appended with a pre-release modifier >> >> e.g. v2.0.0-alpha or v1.0.0-unstable >> >> This is recognised as meaning that the artefact is unstable and the version >> numbering cannot be relied on e.g to assert backward compatibility. >> >> In that sense v0.0.0 and v1.0.0-unstable are identical in terms of their >> ?stability? and lack of commitment to the versioning rules. >> >> So the question for us in the openEHR world is whether tooling should >> support v0.0.0, or simply use v1.0.0-unstable >> >> V0 Advantages >> >> 1. The archetype is clearly marked as immature >> 2. Full compliance with SemVer >> 3. Supported in current test build of CKM >> >> V0 Disadvantages >> >> 1. Tooling e.g Archetype Editor (actually ADL Parser) needs to change to >> support V0 >> 2. Add another layer of complexity to the archetype naming/versioning rules >> 3. Question arises of whether / if to convert current draft V1 CKM >> archetypes to V0 with overhead of explanation to current users. >> 4. Adds complexity where V0 archetypes are being used within templates, when >> the archetype is published and needs to be updated to V1 within these >> templates. >> >> >> V1- Advantages >> >> 1. Compliant with SemVer >> 2. Does not need any changes to Archetype Editor. >> 3. Easier transition between draft and publication states when used within >> templates i.e does not need V0->v1 change >> >> >> V1- Disadvantages >> 1. Does not so clearly differentiate ?first draft? archetype from others >> >> >> Before a final decision is made, we are interested in feedback from the >> community on whether V0 should be implemented in CKM and other openEHR >> tools, although in practice V1- will do an identical job in terms of version >> number governance. >> >> Regards, >> >> Ian McNicoll >> Heather Leslie >> Sebastian Garde >> Thomas Beale >> >> >> >> ___ >> 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 -- *Dr. Sebastian Garde* /Dr. sc. hum., Dipl.-Inform. Med, FACHI/ Ocean Informatics Skype: gardeseb -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/cf40ece8/attachment-0001.html>
Archetype Naming proposals - do we need V0?
planation to current users. >> 4. Adds complexity where V0 archetypes are being used within templates, when >> the archetype is published and needs to be updated to V1 within these >> templates. >> >> >> V1- Advantages >> >> 1. Compliant with SemVer >> 2. Does not need any changes to Archetype Editor. >> 3. Easier transition between draft and publication states when used within >> templates i.e does not need V0->v1 change >> >> >> V1- Disadvantages >> 1. Does not so clearly differentiate ?first draft? archetype from others >> >> >> Before a final decision is made, we are interested in feedback from the >> community on whether V0 should be implemented in CKM and other openEHR >> tools, although in practice V1- will do an identical job in terms of version >> number governance. >> >> Regards, >> >> Ian McNicoll >> Heather Leslie >> Sebastian Garde >> Thomas Beale >> >> >> >> ___ >> openEHR-technical mailing listopenEHR-technical at >> lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >> >> ___ >> openEHR-technical mailing listopenEHR-technical at >> lists.openehr.orghttp://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-clinical mailing list >> openEHR-clinical at lists.openehr.org >> >> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org >> > > > > -- > Dr Ian McNicoll > office / fax +44(0)141 560 4657 > mobile +44 (0)775 209 7859 > skype ianmcnicoll > ian at freshehr.com > > Clinical modelling consultant freshEHR > Director openEHR Foundation > Honorary Senior Research Associate, CHIME, UCL > BCS Primary Health Care www.phcsg.org > > > ___ > openEHR-technical mailing listopenEHR-technical at > lists.openehr.orghttp://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 > -- Dr Ian McNicoll office / fax +44(0)141 560 4657 mobile +44 (0)775 209 7859 skype ianmcnicoll ian at freshehr.com Clinical modelling consultant freshEHR Director openEHR Foundation Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care www.phcsg.org -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/2123e600/attachment-0001.html>
Archetype Naming proposals - do we need V0?
Hi Thomas and all, On 01.10.2014 14:07, Thomas Beale wrote: > On 01/10/2014 11:23, Ian McNicoll wrote: >> In that sense v0.0.0 and v1.0.0-unstable are identical in terms of >> their ?stability? and lack of commitment to the versioning rules. > > > I don't think this is true. Firstly, the standard first possible > version is v0.0.1 in any versioning environment I know of; secondly, > the rules that I thought we were adopting have the following implications: > > * an uncontrolled archetype is uploaded for the first time, with > version v0.N.P > * at some point in the CKM environment is becomes v1.0.0, which is > the first possible version at which it could be published > o let's just say for argument's sake, it is first published at > v1.2.0 > The point when it becomes v1.0.0 is when the archetype is first published - i.e. the first published version will always be 1.0.0 and not v1.2.0 If the transition to v1.0.0 comes from v0.0.1[-unstable] or v1.0.0-unstable doesn't really matter - purely technically speaking the terms of stability and lack of commitment are the same for both 0.0.1[-unstable] and v1.0.0-unstable > > 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) > * 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 don't see the problem with v0 references in templates, since > it's the same problem between any major version. An archetype > .v0.x can't be assumed to be compatible with .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. Sebastian -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/dd4685b1/attachment-0001.html>
Archetype Naming proposals - do we need V0?
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 >> .v0.x can't be assumed to be compatible with .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 -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/d527e646/attachment-0001.html>
Archetype Naming proposals - do we need V0?
-technical mailing listopenEHR-technical at > lists.openehr.orghttp://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-clinical mailing list > openEHR-clinical at lists.openehr.org > > http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org > -- Dr Ian McNicoll office / fax +44(0)141 560 4657 mobile +44 (0)775 209 7859 skype ianmcnicoll ian at freshehr.com Clinical modelling consultant freshEHR Director openEHR Foundation Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care www.phcsg.org -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/a7077055/attachment.html>
Archetypes vs. Templates, archetype version in slots
On 30/09/2014 22:33, Ian McNicoll wrote: > Hi Diego, > > I understand your point but I am not sure that slot naming is really > working out as any of us envisaged. In the vast majority of cases > where we specify an archetype pattern in the slot description we also > leave the constraint open-ended because experience has shown us that > too tightly coupling the parent and child leads to over-complication > of dependencies and insufficient flexibility to cope with new use > cases. In this respect the slot filling constraint acts as useful > 'design guidance' i.e this is the sort of archetype we expect to be > slotted in here but others (including V2 versions are allowed). it might be worth noting that slots and external references (i.e. direct references to archetypes, without the slot) have identifiers, like all nodes, in ADL/AOM 1.5, and also that external references are used ubiquitously in CIMI, which are all named (if you mean that they have 'meanings', i.e. id-code references). We also have to remember that 13606 and other archetype formalism users might have quite different styles of use, as CIMI does. - thomas -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/9122c4fa/attachment.html>
Archetype Naming proposals - do we need V0?
> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org > -- Dr Ian McNicoll office +44 (0)1536 414 994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical Modelling Consultant, Ocean Informatics, UK Director openEHR Foundation www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL SCIMP Working Group, NHS Scotland BCS Primary Health Care www.phcsg.org -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/d1d15b1d/attachment.html>
Archetype Naming proposals - do we need V0?
> > 2. Does not need any changes to Archetype Editor. > > 3. Easier transition between draft and publication states when used > within > > templates i.e does not need V0->v1 change > > > > > > V1- Disadvantages > > 1. Does not so clearly differentiate ?first draft? archetype from others > > > > > > Before a final decision is made, we are interested in feedback from the > > community on whether V0 should be implemented in CKM and other openEHR > > tools, although in practice V1- will do an identical job in terms of > version > > number governance. > > > > Regards, > > > > Ian McNicoll > > Heather Leslie > > Sebastian Garde > > Thomas Beale > > > > > > > > ___ > > 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 > -- Dr Ian McNicoll office / fax +44(0)141 560 4657 mobile +44 (0)775 209 7859 skype ianmcnicoll ian at freshehr.com Clinical modelling consultant freshEHR Director openEHR Foundation Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care www.phcsg.org -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/5e3acadc/attachment.html>
Archetype Naming proposals - do we need V0?
On 01/10/2014 11:23, Ian McNicoll wrote: > > > In that sense v0.0.0 and v1.0.0-unstable are identical in terms of > their 'stability' and lack of commitment to the versioning rules. Hi Ian, I don't think this is true. Firstly, the standard first possible version is v0.0.1 in any versioning environment I know of; secondly, the rules that I thought we were adopting have the following implications: * an uncontrolled archetype is uploaded for the first time, with version v0.N.P * at some point in the CKM environment is becomes v1.0.0, which is the first possible version at which it could be published o let's just say for argument's sake, it is first published at v1.2.0 * later, it goes back for revision, which means according to the state diagram in the latest draft <http://www.openehr.org/wiki/download/attachments/5996562/artefact_lifecycle_versioning.png?version=3&modificationDate=1412031989000&api=v2>, its next version has to be v1.2.1-unstable, i.e. one patch ahead of v1.2.0, the last published version o the meaning of this, as I understood it was that this version is 'at least' one patch level different from the version at the preceding patch value (v1.2.0), and also unstable, meaning that it might have more differences than jst that. * when it is ready for publishing, its version is adjusted, with the help of a diff tool, to the actual version it is required to be according to the type of diffs present. E.g. it might have to be v1.3.0. So the new vresion is either v1.3.0 or v1.3.0-rc.B, if the release candidate path is being used. 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. I'm not that worried about 'compliance with SemVer' - it's more that v0 is universally understood as indicating early chaotic development - it's a universal 'play with me, but don't trust me' sign. By that argument we also know that any version v1 or higher must be from a controlled governance environment like a CKM or similar. In terms of possible concerns listed below: * There is no doubt changes are needed to various tooling, but that's the situation anyway, e.g. to implement namespaces or other changes. * 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. o You might possibly petition the clinical list to find out if anyone has ever used an archetype mooted for v0 renaming, in any production context. * I don't see the problem with v0 references in templates, since it's the same problem between any major version. An archetype .v0.x can't be assumed to be compatible with .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. I may still be missing something here, so this analysis is what seems sensible to me based on what I know today. - thomas -- next part ------ An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/cf9b9cc0/attachment.html>
Archetype Naming proposals - do we need V0?
I tested v0 with LinkEHR editor and works just fine. I think that 'v1.0.0-unstable' has additional problems, such as deciding which words are allowed (e.g 'unstable', 'firstdraft', 'alpha', etc.), which means that tools have to be modified anyway. Arguably, is better to widen a range than to parse specific strings which end changing in the end. Also, adding this breaks all current v1 slots (related to my last question to the list) v0 is also fully compliant with SemVer, which means that in theory archetype identifiers won't need to be changed when we move to ADL1.5 (going with v1-unestable will need another change in the future) 2014-10-01 12:23 GMT+02:00 Ian McNicoll : > > Hi all, > > Apologies for cross-posting in both clinical and technical but this does > neatly cross that divide. > > We are getting close in CKM to implementing the ADL1.5 archetype naming > /versioning rules proposed at > > http://www.openehr.org/wiki/display/ADL/Knowledge+Artefact+Identification > > mostly by adding the metadata to the ADL other_details section, which means > we can carry the information in ADL 1.4 archetypes without disturbing > current systems. > > These latest proposals are now very much in line with the de-facto standard > SemVer 2.0 see http://semver.org which allows > > major revision > minor revision > patch > build > > but one of the questions which remains controversial is whether to support a > major revision of V0 (as allowed in SemVer). > > In Semver, V0 is allowed for very immature ?first draft? semantic > artefacts/APIs prior to initial release but SemVer allows for any revision > to appended with a pre-release modifier > > e.g. v2.0.0-alpha or v1.0.0-unstable > > This is recognised as meaning that the artefact is unstable and the version > numbering cannot be relied on e.g to assert backward compatibility. > > In that sense v0.0.0 and v1.0.0-unstable are identical in terms of their > ?stability? and lack of commitment to the versioning rules. > > So the question for us in the openEHR world is whether tooling should > support v0.0.0, or simply use v1.0.0-unstable > > V0 Advantages > > 1. The archetype is clearly marked as immature > 2. Full compliance with SemVer > 3. Supported in current test build of CKM > > V0 Disadvantages > > 1. Tooling e.g Archetype Editor (actually ADL Parser) needs to change to > support V0 > 2. Add another layer of complexity to the archetype naming/versioning rules > 3. Question arises of whether / if to convert current draft V1 CKM > archetypes to V0 with overhead of explanation to current users. > 4. Adds complexity where V0 archetypes are being used within templates, when > the archetype is published and needs to be updated to V1 within these > templates. > > > V1- Advantages > > 1. Compliant with SemVer > 2. Does not need any changes to Archetype Editor. > 3. Easier transition between draft and publication states when used within > templates i.e does not need V0->v1 change > > > V1- Disadvantages > 1. Does not so clearly differentiate ?first draft? archetype from others > > > Before a final decision is made, we are interested in feedback from the > community on whether V0 should be implemented in CKM and other openEHR > tools, although in practice V1- will do an identical job in terms of version > number governance. > > Regards, > > Ian McNicoll > Heather Leslie > Sebastian Garde > Thomas Beale > > > > ___ > openEHR-clinical mailing list > openEHR-clinical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
Archetype Naming proposals - do we need V0?
.0.0-unstable > > > > V0 Advantages > > > > 1. The archetype is clearly marked as immature > > 2. Full compliance with SemVer > > 3. Supported in current test build of CKM > > > > V0 Disadvantages > > > > 1. Tooling e.g Archetype Editor (actually ADL Parser) needs to change to > > support V0 > > 2. Add another layer of complexity to the archetype naming/versioning > rules > > 3. Question arises of whether / if to convert current draft V1 CKM > > archetypes to V0 with overhead of explanation to current users. > > 4. Adds complexity where V0 archetypes are being used within templates, > when > > the archetype is published and needs to be updated to V1 within these > > templates. > > > > > > V1- Advantages > > > > 1. Compliant with SemVer > > 2. Does not need any changes to Archetype Editor. > > 3. Easier transition between draft and publication states when used > within > > templates i.e does not need V0->v1 change > > > > > > V1- Disadvantages > > 1. Does not so clearly differentiate ?first draft? archetype from others > > > > > > Before a final decision is made, we are interested in feedback from the > > community on whether V0 should be implemented in CKM and other openEHR > > tools, although in practice V1- will do an identical job in terms of > version > > number governance. > > > > Regards, > > > > Ian McNicoll > > Heather Leslie > > Sebastian Garde > > Thomas Beale > > > > > > > > ___ > > 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 Ian McNicoll office +44 (0)1536 414 994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical Modelling Consultant, Ocean Informatics, UK Director openEHR Foundation www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL SCIMP Working Group, NHS Scotland BCS Primary Health Care www.phcsg.org -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/7757fd2a/attachment.html>
Archetype Naming proposals - do we need V0?
/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 Ian McNicoll office / fax +44(0)141 560 4657 mobile +44 (0)775 209 7859 skype ianmcnicoll ian at freshehr.com Clinical modelling consultant freshEHR Director openEHR Foundation Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care www.phcsg.org -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/20ca5421/attachment-0001.html>
Archetype Naming proposals - do we need V0?
Hi Ian, Personally I think V0 has significant costs in exchange for not so significant benefits. Semver compatibility would be nice, but nice is not worth the implementation cost for parser etc here. I don't know if V0 support would break things deep down in actual openEHR implementations but even that may be a possibility if there is a reg-ex sitting in some code that expects v1 as the starting point. The features in adl 1.5 would probably help provide a workaround to express the semantics that would otherwise be expressed with V0 Best regards Seref On Wed, Oct 1, 2014 at 11:23 AM, Ian McNicoll wrote: > > Hi all, > > Apologies for cross-posting in both clinical and technical but this does > neatly cross that divide. > > We are getting close in CKM to implementing the ADL1.5 archetype naming > /versioning rules proposed at > > *http://www.openehr.org/wiki/display/ADL/Knowledge+Artefact+Identification* > <http://www.openehr.org/wiki/display/ADL/Knowledge+Artefact+Identification> > > mostly by adding the metadata to the ADL other_details section, which > means we can carry the information in ADL 1.4 archetypes without disturbing > current systems. > > These latest proposals are now very much in line with the de-facto > standard SemVer 2.0 see http://semver.org which allows > > major revision > minor revision > patch > build > > but one of the questions which remains controversial is whether to support > a major revision of V0 (as allowed in SemVer). > > In Semver, V0 is allowed for very immature ?first draft? semantic > artefacts/APIs prior to initial release but SemVer allows for any revision > to appended with a pre-release modifier > > e.g. v2.0.0-alpha or v1.0.0-unstable > > This is recognised as meaning that the artefact is unstable and the > version numbering cannot be relied on e.g to assert backward compatibility. > > In that sense v0.0.0 and v1.0.0-unstable are identical in terms of their > ?stability? and lack of commitment to the versioning rules. > > So the question for us in the openEHR world is whether tooling should > support v0.0.0, or simply use v1.0.0-unstable > > V0 Advantages > > 1. The archetype is clearly marked as immature > 2. Full compliance with SemVer > 3. Supported in current test build of CKM > > V0 Disadvantages > > 1. Tooling e.g Archetype Editor (actually ADL Parser) needs to change to > support V0 > 2. Add another layer of complexity to the archetype naming/versioning rules > 3. Question arises of whether / if to convert current draft V1 CKM > archetypes to V0 with overhead of explanation to current users. > 4. Adds complexity where V0 archetypes are being used within templates, > when the archetype is published and needs to be updated to V1 within these > templates. > > > V1- Advantages > > 1. Compliant with SemVer > 2. Does not need any changes to Archetype Editor. > 3. Easier transition between draft and publication states when used within > templates i.e does not need V0->v1 change > > > V1- Disadvantages > 1. Does not so clearly differentiate ?first draft? archetype from others > > > Before a final decision is made, we are interested in feedback from the > community on whether V0 should be implemented in CKM and other openEHR > tools, although in practice V1- will do an identical job in terms of > version number governance. > > Regards, > > Ian McNicoll > Heather Leslie > Sebastian Garde > Thomas Beale > > > > ___ > 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/cb621a28/attachment.html>
Archetype Naming proposals - do we need V0?
Hi all, Apologies for cross-posting in both clinical and technical but this does neatly cross that divide. We are getting close in CKM to implementing the ADL1.5 archetype naming /versioning rules proposed at *http://www.openehr.org/wiki/display/ADL/Knowledge+Artefact+Identification* <http://www.openehr.org/wiki/display/ADL/Knowledge+Artefact+Identification> mostly by adding the metadata to the ADL other_details section, which means we can carry the information in ADL 1.4 archetypes without disturbing current systems. These latest proposals are now very much in line with the de-facto standard SemVer 2.0 see http://semver.org which allows major revision minor revision patch build but one of the questions which remains controversial is whether to support a major revision of V0 (as allowed in SemVer). In Semver, V0 is allowed for very immature ?first draft? semantic artefacts/APIs prior to initial release but SemVer allows for any revision to appended with a pre-release modifier e.g. v2.0.0-alpha or v1.0.0-unstable This is recognised as meaning that the artefact is unstable and the version numbering cannot be relied on e.g to assert backward compatibility. In that sense v0.0.0 and v1.0.0-unstable are identical in terms of their ?stability? and lack of commitment to the versioning rules. So the question for us in the openEHR world is whether tooling should support v0.0.0, or simply use v1.0.0-unstable V0 Advantages 1. The archetype is clearly marked as immature 2. Full compliance with SemVer 3. Supported in current test build of CKM V0 Disadvantages 1. Tooling e.g Archetype Editor (actually ADL Parser) needs to change to support V0 2. Add another layer of complexity to the archetype naming/versioning rules 3. Question arises of whether / if to convert current draft V1 CKM archetypes to V0 with overhead of explanation to current users. 4. Adds complexity where V0 archetypes are being used within templates, when the archetype is published and needs to be updated to V1 within these templates. V1- Advantages 1. Compliant with SemVer 2. Does not need any changes to Archetype Editor. 3. Easier transition between draft and publication states when used within templates i.e does not need V0->v1 change V1- Disadvantages 1. Does not so clearly differentiate ?first draft? archetype from others Before a final decision is made, we are interested in feedback from the community on whether V0 should be implemented in CKM and other openEHR tools, although in practice V1- will do an identical job in terms of version number governance. Regards, Ian McNicoll Heather Leslie Sebastian Garde Thomas Beale -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/c3092858/attachment.html>
openEHR archetype publication sprint IS GO!
.openehr.org/wiki/display/healthmod/Review+archetype+content There are also a couple of videos that provide an overview of the CKM and Reviewing an archetype: http://www.openehr.org/wiki/display/healthmod/Clinical+Knowledge+Manager+Video+Tutorials Looking forward to having you involved during the sprint. Please share this email with anyone who you think may be interested. Many thanks Heather Leslie Dr Heather Leslie MBBS FRACGP FACHI Director/Consulting Lead Ocean Informatics<http://www.oceaninformatics.com/> Phone - +61 418 966 670 Skype - heatherleslie Twitter - @omowizard [16] [2013 Health-Partner-of-the-Year] -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/9a5cb048/attachment-0001.html> -- next part -- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 5944 bytes Desc: image001.gif URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/9a5cb048/attachment-0002.gif> -- next part -- A non-text attachment was scrubbed... Name: image002.gif Type: image/gif Size: 5607 bytes Desc: image002.gif URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/9a5cb048/attachment-0003.gif>
openEHR archetype publication sprint IS GO!
[16] [2013 Health-Partner-of-the-Year] -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/d3239487/attachment-0001.html> -- next part -- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 5944 bytes Desc: image001.gif URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/d3239487/attachment-0002.gif> -- next part -- A non-text attachment was scrubbed... Name: image002.gif Type: image/gif Size: 5607 bytes Desc: image002.gif URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/d3239487/attachment-0003.gif>
