Good point Sebastian, I was really thinking towards the future and the same slot constraints appearing or being redefined in templates where tighter constraints might be needed.
Is that overkill? Ian Dr Ian McNicoll mobile +44 (0)775 209 7859 office +44 (0)1536 414994 skype: ianmcnicoll email: i...@freshehr.com twitter: @ianmcnicoll Co-Chair, openEHR Foundation ian.mcnic...@openehr.org Director, freshEHR Clinical Informatics Ltd. Director, HANDIHealth CIC Hon. Senior Research Associate, CHIME, UCL On 22 July 2015 at 15:26, Sebastian Garde < sebastian.ga...@oceaninformatics.com> wrote: > My understanding was that minor version and patch version would not be > part of the normal archetype id, which is what you are looking for here? > Otherwise you'd need to allow "-alpha" etc here as well? > > Sebastian > > > > On 22.07.2015 16:00, Ian McNicoll wrote: > > That will be the one then. > > Thx > > Ian > On Wed, 22 Jul 2015 at 14:29, Diego Boscá < <yamp...@gmail.com> > yamp...@gmail.com> wrote: > >> Second one allows both the new and the old versioning (e.g. v0.0.5 vs v0) >> El 22/7/2015 15:12, "Ian McNicoll" <i...@freshehr.com> escribió: >> >>> Thanks Diego >>> >>> What is the difference between the 2 ? >>> >>> Ian >>> On Wed, 22 Jul 2015 at 13:55, Diego Boscá <yamp...@gmail.com> wrote: >>> >>>> Put v[0-9] or v[0-9](\.[0-9])* to allow multiple subversions >>>> El 22/7/2015 14:22, "Ian McNicoll" <i...@freshehr.com> escribió: >>>> >>>>> Hi Dave, >>>>> >>>>> I recognise the problem which is a result of the transition to a >>>>> much richer and better versioning mechanism. >>>>> >>>>> The Archetype Editor has been updated to handle the new versioning >>>>> (on the openEHR Github, not released yet ) but we will need to adapt the >>>>> slot fill regex to allow for .v0 archetypes, which are now the default for >>>>> new, uncontrolled archetypes. >>>>> >>>>> The default regex for slot-fill pattern needs to be changed to allow >>>>> any Version not just V1 >>>>> >>>>> openEHR-EHR-CLUSTER\.context_detail(-[a-zA-Z0-9_]+)*\.v1/} >>>>> >>>>> I am not a regex expert - If someone can guide me on how to change >>>>> this to allow .v*, I can update the AE code. >>>>> >>>>> We will almost certainly have to edit some legacy archetype ADL as >>>>> well. >>>>> >>>>> Ian >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Dr Ian McNicoll >>>>> mobile +44 (0)775 209 7859 <%2B44%20%280%29775%20209%207859> >>>>> office +44 (0)1536 414994 <%2B44%20%280%291536%20414994> >>>>> >>>> >>>>> skype: ianmcnicoll >>>>> email: <i...@freshehr.com>i...@freshehr.com >>>>> twitter: @ianmcnicoll >>>>> >>>>> Co-Chair, openEHR Foundation >>>>> <ian.mcnic...@openehr.org>ian.mcnic...@openehr.org >>>>> Director, freshEHR Clinical Informatics Ltd. >>>>> Director, HANDIHealth CIC >>>>> Hon. Senior Research Associate, CHIME, UCL >>>>> >>>> >>>>> On 22 July 2015 at 12:33, Barnet David (HEALTH AND SOCIAL CARE >>>>> INFORMATION CENTRE) < <david.bar...@hscic.gov.uk> >>>>> david.bar...@hscic.gov.uk> wrote: >>>>> >>>>>> Hi All >>>>>> >>>>>> >>>>>> >>>>>> I’m having a bit of an issue with CKM re-versioning archetypes and >>>>>> slots that reference Clusters. >>>>>> >>>>>> >>>>>> >>>>>> When I create a new archetype in the archetype editor (Version >>>>>> 2.2.905 Beta), the archetype is saved as version 1. For example >>>>>> >>>>>> “openEHR-EHR-OBSERVATION. blood_pressure.v1.adl” >>>>>> >>>>>> >>>>>> >>>>>> When I upload the archetype to CKM, the process renames the archetype >>>>>> to version 0 – for example “openEHR-EHR-OBSERVATION. blood_pressure.v0” >>>>>> (we >>>>>> are hosted on version 1.4.0 of the Clinical Knowledge Manager) >>>>>> >>>>>> >>>>>> >>>>>> The re-versioning becomes an issue when I use slots. In the >>>>>> Archetype editor I can assign a slot to a Cluster (for example), but this >>>>>> process creates a link to a version of the Cluster. If it’s a new >>>>>> Cluster, >>>>>> this will be version 1. When the Cluster and the archetype are uploaded >>>>>> to >>>>>> the CKM, they are both put back to version 0. However, the slot Cluster >>>>>> is >>>>>> looking for version 1 of the Cluster, which won’t exist on the CKM (so >>>>>> CKM >>>>>> can’t make the link between these 2 objects). >>>>>> >>>>>> >>>>>> >>>>>> Does anyone have a work-around, or have some advice and guidance, for >>>>>> this issue? >>>>>> >>>>>> >>>>>> >>>>>> Kind Regards >>>>>> >>>>>> >>>>>> >>>>>> Dave Barnet >>>>>> Interoperability Lead >>>>>> >>>>>> Interoperability Specifications >>>>>> >>>>>> Health & Social Care Information Centre >>>>>> david.bar...@hscic.gov.uk >>>>>> www.hscic.gov.uk >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> ******************************************************************************************************************** >>>>>> >>>>>> This message may contain confidential information. If you are not the >>>>>> intended recipient please inform the >>>>>> sender that you have received the message in error before deleting it. >>>>>> Please do not disclose, copy or distribute information in this e-mail >>>>>> or take any action in reliance on its contents: >>>>>> to do so is strictly prohibited and may be unlawful. >>>>>> >>>>>> Thank you for your co-operation. >>>>>> >>>>>> NHSmail is the secure email and directory service available for all >>>>>> NHS staff in England and Scotland >>>>>> NHSmail is approved for exchanging patient data and other sensitive >>>>>> information with NHSmail and GSi recipients >>>>>> NHSmail provides an email address for your career in the NHS and can >>>>>> be accessed anywhere >>>>>> >>>>>> >>>>>> ******************************************************************************************************************** >>>>>> >>>>>> _______________________________________________ >>>>>> openEHR-technical mailing list >>>>>> openEHR-technical@lists.openehr.org >>>>>> >>>>>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> openEHR-technical mailing list >>>>> openEHR-technical@lists.openehr.org >>>>> >>>>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >>>>> >>>> _______________________________________________ >>>> openEHR-technical mailing list >>>> openEHR-technical@lists.openehr.org >>>> >>>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >>>> >>> >>> _______________________________________________ >>> openEHR-technical mailing list >>> openEHR-technical@lists.openehr.org >>> >>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >>> >> _______________________________________________ >> openEHR-technical mailing list >> openEHR-technical@lists.openehr.org >> >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >> > > > _______________________________________________ > openEHR-technical mailing > listopenEHR-technical@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 > > > ------------------------------ > [image: Avast logo] <https://www.avast.com/antivirus> > > Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft. > www.avast.com <https://www.avast.com/antivirus> > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical@lists.openehr.org > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >
_______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
