I assume the discussion relates to versions in the repository. If I test a non-draft template with a draft archetype, archetype.V2draft.template.Vn would only exist outside, but shouldn't the definition be complete....
Ref: https://svn.connectingforhealth.nhs.uk/svn/public/nhscontentmodels/doc/common/CM_Processes_Overview.pdf Regards, Colin -----Original Message----- From: [email protected] on behalf of Thomas Beale Sent: Fri 25-Jul-08 5:54 PM To: For openEHR technical discussions Subject: Re: Release 1.0.2 change - SPEC-260 -Correct the regex publishedfortheARCHETYPE_ID type (due date 304/Aug/08) We just need to decide how many parts the version number could possibly have in the future - if it is 2, then fine by me - we can easily adjust the regex. - thomas Sam Heard wrote: > Hi Tom > > I just want to make it known that I am concerned about archetype Ids > with two decimal points in the version. I am not sure that we will > know what this means. To me there are only two possibilities: > > 1. a new archetype revision means that all data out there is still > compatible > 2. a new archetype version that means that some data out there is > incompatible > > A revised archetype means that queries against the old archetype will > still work in the new archetype and visa versa. It is for this reason > that I have been relucent to have revisions labelled in the ID. It > makes sense at one level, but it greatly adds to the complexity of > running queries, managing templates etc. I know it makes the > technicians faint to think that a revised and fully backwardly > compatible archetype might be released with the same ID, but with the > generally extensible nature of the approach this has a lot of benefits > (see below). Clearly, this can only be done from a central source - > local changes (ie not done at the openEHR level) will need to be > specialised to ensure that there is clear governance and control. > > I think we need to stay out on this one until we are clearer on > whether Templates having to be manually updated each time an archetype > is updated, or allowing features of the new archetype to appear in > templates as the default (given that peer nodes in the archetype do > appear in the template). > > Whatever the way we go with this, I do not think we want 1.1.1 unless > people can come up with a sensible reason to have three levels. I > can't think of any benefit. > > Cheers, Sam > > Thomas Beale wrote: >> I now have the grammar and PERL regex as below. This is slightly >> improved (I believe) from Peter's last version. >> >> >> >> archetype_id: qualified_rm_entity '.' domain_concept '.' version_id >> >> qualified_rm_entity: rm_originator '-' rm_name '-' rm_entity >> rm_originator: V_NAME >> rm_name: V_NAME >> rm_entity: V_NAME >> >> domain_concept: concept_name { '-' specialisation } >> concept_name: V_NAME >> specialisation: V_NAME >> >> version_id: 'v' V_NONZERO_DIGIT [ V_NUMBER ] [ '.' V_NUMBER [ '.' >> V_NUMBER ] ] >> >> V_NONZERO_DIGIT: [1-9] >> V_DIGIT: [0-9] >> V_NUMBER: [0-9]* >> V_NAME: [a-zA-Z][a-zA-Z0-9_]+ >> >> >> The PERL regular expression equivalent of the above is as follows: >> [a-zA-Z]\w+(-[a-zA-Z]\w+){2}\.[a-zA-Z]\w+(-[a-zA-Z]\w+)*\.v[1-9]\d*(\.\d+){0,2} >> >> Peter Gummer wrote: >> >>> Thomas Beale wrote: >>> >>> >>>>> v1.1.1.1 -- or even more than three parts? >>>>> >>>>> >>>> yes you are right - we probably should limit it to 3, which will >>>> require a change >>>> >>>> >>>> >>>>> The version_id regex rejects these: ... >>>>> v1.10 -- surely this should be allowed! >>>>> >>>>> >>>> yes - that's an error. I think this part of the regex should be: >>>> >>>> .v[1-9]\d*(\.[0-9]+){0,2} >>>> >>>> >>> Ok, so in Perlesque it would be: >>> >>> v[1-9]\d*(\.\d+){0,2} >>> >>> And the "classic regular expression equivalent" would be: >>> >>> v[1-9][0-9]*(\.[0-9]+){0,2} >>> >>> Therefore, the production rule would be: >>> >>> version_id: 'v' V_NONZERO_DIGIT { V_DIGIT } [ '.' V_DIGIT { V_DIGIT } >>> ] >>> [ '.' V_DIGIT { V_DIGIT } ] >>> V_DIGIT: [0-9] >>> V_NONZERO_DIGIT: [1-9] >>> >>> - Peter >>> >>> >>> _______________________________________________ >>> openEHR-technical mailing list >>> openEHR-technical at openehr.org >>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >>> >>> >>> >>> >> >> >> > > -- > > Dr Sam Heard > Chief Executive Officer > Director, openEHR Foundation > Senior Visiting Research Fellow, University College London > 214 Victoria Avenue > Chatswood, NSW, 2067 > Phone: +61 2 9415 4994 > Mobile: +61 4 1783 8808 21 Chester Cres > London E8 2PH > Phone: +44 20 7249 7085 > Mobile: +44 77 9871 0980 > > > ------------------------------------------------------------------------ > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > -- *Thomas Beale Chief Technology Officer, Ocean Informatics <http://www.oceaninformatics.com/>* Chair Architectural Review Board, /open/EHR Foundation <http://www.openehr.org/> Honorary Research Fellow, University College London <http://www.chime.ucl.ac.uk/> * * _______________________________________________ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical ##################################################################################### This e-mail message has been scanned for Viruses and Content and cleared by MailMarshal ##################################################################################### #################################################################################################################### IMPORTANT NOTICE: This e-mail and any attachment to it are intended only to be read or used by the named addressee. It is confidential and may contain legally privileged information. No confidentiality or privilege is waived or lost by any mistaken transmission to you. The CTC is not responsible for any unauthorised alterations to this e-mail or attachment to it. Views expressed in this message are those of the individual sender, and are not necessarily the views of the CTC. If you receive this e-mail in error, please immediately delete it and notify the sender. You must not disclose, copy or use any part of this e-mail if you are not the intended recipient. ##################################################################################################################### -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 7458 bytes Desc: not available URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080725/442c0ac0/attachment.dat>
