Thanks Seref, That is my feeling exactly. In practical terms, in an openEHR context, .V0 and .v1-unstable are identical. We do know that V0 breaks the old AE Eiffel parser. This is probably easily fixable but is an example of work that would need to be done.
We are replicating the ADL 1.5 features as you suggest but in a way that does not change core archetype identification in ADL1.4, other than .V0. Perhaps the compromise is to defer the decision until tooling and systems are ready to use ADL1.5, by which time we will have experience with V1-unstable and have a better understanding of whether V0 is really necessary. Ian On 1 October 2014 11:34, Seref Arikan <serefarikan at kurumsalteknoloji.com> wrote: > 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 <ian at mcmi.co.uk> 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 >> > > > _______________________________________________ > 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>
