Skip to Navigation | Skip to Content

openEHR-Technical mailing list archives

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

RE: Release 1.0.2 change - SPEC-260 -Correct the regex publishedfortheAR

  • To: "For openEHR technical discussions" <openehr-technical@openehr.org>
  • Subject: RE: Release 1.0.2 change - SPEC-260 -Correct the regex publishedfortheARCHETYPE_ID type (due date 304/Aug/08)
  • From: "Colin Sutton" <ColinS@ctc.usyd.edu.au>
  • Date: Fri, 25 Jul 2008 20:42:00 +1000
  • Thread-index: AcjuLahXeRj1QXWURu60vHxXPZ/qZQAEqwjr
  • Thread-topic: Release 1.0.2 change - SPEC-260 -Correct the regex publishedfortheARCHETYPE_ID type (due date 304/Aug/08)

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: openehr-technical-bounces@openehr.org 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@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@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@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.

#####################################################################################################################

<<winmail.dat>>

_______________________________________________
openEHR-technical mailing list
openEHR-technical@openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical