Dear all,
The CR SPEC-260 (http://www.openehr.org/issues/browse/SPEC-260) being
processed for Release-1.0.2 proposes an updated regular expression and
syntax to match Archetype identifiers. The changes are visible in
section 4.3.10 of the Support IM document at
http://www.openehr.org/svn/specification/BRANCHES/Release-1.0.2-candidate/publishing/architecture/rm/support_im.pdf
Any feedback on the proposed regular expression would be appreciated.
- thomas beale
Thomas Beale wrote:
The CR SPEC-260 (http://www.openehr.org/issues/browse/SPEC-260) being
processed for Release-1.0.2 proposes an updated regular expression and
syntax to match Archetype identifiers. The changes are visible in
section 4.3.10 of the Support IM document at
http://www.openehr.org/svn/specification/BRANCHES/Release-1.0.2-candidate/publishing/architecture/rm/support_im.pdf
The regular expressions in section 4.3.10 are a big improvement, but there
are some errors and surprises.
The first surprise is that single-character specialisation concepts are now
rejected. They used to be accepted. (An example would be "blood_type-o".)
It's now consistent with the pattern for the concept name. Was this change
intentional?
The version_id part of the regex -- v[1-9]\d*(\.\d)* -- has bigger problems.
In section 4.3.10, the regex matches these version_ids:
v1 -- good
v10 -- good
v1.0 -- is this intentional to allow a zero in a minor version
part?
v1.1 -- good
v1.1.1 -- is this intentional to allow three parts?
v1.1.1.1 -- or even more than three parts?
The version_id regex rejects these:
v0 -- good, this was Eric Browne's point that version_id
shouldn't be zero
v1.10 -- surely this should be allowed!
I believe the version_id regex should be one of the following:
[R1] v[1-9]\d*(\.\d+)* -- allows v1.10
[R2] v[1-9]\d*(\.[1-9]\d*)* -- allows v1.10 and disallows v1.0
[R3] v[1-9]\d*(\.\d+)? -- allows v1.10 and disallows v1.1.1
[R3] v[1-9]\d*(\.[1-9]\d*)? -- allows v1.10 and disallows v1.1.1 and
v1.0
Another error is that the production rules in section 4.3.10 are
inconsistent with the version_id regex:
version_id: 'v' V_NATURAL_DIGIT { '.' V_NUMBER }*
V_NUMBER: [0-9]*
V_NATURAL_DIGIT: [1-9]
V_NAME: [a-zA-Z][a-zA-Z0-9_]+
The corresponding regex would be v[1-9](\.\d*)* , which differs from section
4.3.10's regex in three respects:
* It allows "v1.10", which surely is good; but
* It allows "v1.", and
* It disallows "v10"!
So, once the regex is right, the production rules have to be fixed too.
- Peter
I knew someone would leap in and help 
Peter Gummer wrote:
The first surprise is that single-character specialisation concepts are now
rejected. They used to be accepted. (An example would be "blood_type-o".)
It's now consistent with the pattern for the concept name. Was this change
intentional?
It was - whether or not it is correct or required is another matter -
the archetype community needs to decide that. I would suggest that
"blood_type-o" could not be a sensible archetype name from a clinical
point of view, because 'o' is not a specialisation of the blood type
reporting concept, it is a blood type in reality. I.e. in Snomed would
would find
blood type
^
blood type O
but it doesn't make sense in archetypes that I can see.
I think we would need at least one realistic example of where a name
needs to be only one character long before we allowed it.
The version_id part of the regex -- v[1-9]\d*(\.\d)* -- has bigger problems.
In section 4.3.10, the regex matches these version_ids:v1 -- good
v10 -- good
v1.0 -- is this intentional to allow a zero in a minor version
part?
yes
v1.1 -- good
v1.1.1 -- is this intentional to allow three parts?
yes
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:
v0 -- good, this was Eric Browne's point that version_id
shouldn't be zero
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}
I believe the version_id regex should be one of the following:
[R1] v[1-9]\d*(\.\d+)* -- allows v1.10
[R2] v[1-9]\d*(\.[1-9]\d*)* -- allows v1.10 and disallows v1.0
[R3] v[1-9]\d*(\.\d+)? -- allows v1.10 and disallows v1.1.1
[R3] v[1-9]\d*(\.[1-9]\d*)? -- allows v1.10 and disallows v1.1.1 and
v1.0Another error is that the production rules in section 4.3.10 are
inconsistent with the version_id regex:version_id: 'v' V_NATURAL_DIGIT { '.' V_NUMBER }*
V_NUMBER: [0-9]*
V_NATURAL_DIGIT: [1-9]
V_NAME: [a-zA-Z][a-zA-Z0-9_]+The corresponding regex would be v[1-9](\.\d*)* , which differs from section
4.3.10's regex in three respects:* It allows "v1.10", which surely is good; but
* It allows "v1.", and
* It disallows "v10"!So, once the regex is right, the production rules have to be fixed too.
yep...!
- thomas beale
Thomas Beale wrote:
... They used to be accepted. (An example would be "blood_type-o".) ...
... I would suggest that
"blood_type-o" could not be a sensible archetype name from a clinical
point of view, because 'o' is not a specialisation of the blood type
reporting concept ...I think we would need at least one realistic example of where a name
needs to be only one character long before we allowed it.
Sure. I wasn't really trying to present "blood_type-o" as a realistic
clinical example, and I agree it isn't. It was intended as a technical
example; "xx-x" is another example.
When trying to come up with a realistic example, however, I think we should
consider more than just openEHR domain concepts. Archetypes are potentially
applicable to any domain, not just to clinical concepts. It strikes me that,
whereas it would never be realistic to have a single-character concept name
(or at least not in English, although I wonder whether even this assumption
holds in, say, Chinese or Japanese), the idea of a single character concept
specialisation is quite plausible.
No realistic example has popped into my head, however, while writing this
reply.
- Peter
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 changeThe 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
While you are looking at the regex rules, could you revisit the way that
'any specialisation of' is handled with respect to version numbers?
The current version of the regex allows symptom.v1* eg symptom-pain.v1
wheras the v1 should probably refer to the parent. Do we need to
consider versioning for both parent and specialisation?
Symptom.v1-pain.v3.3
Ian
Dr Ian McNicoll
office / fax +44(0)141 560 4657
mobile +44 (0)775 209 7859
skype ianmcnicoll
Consultant - Ocean Informatics ian.mcnicoll@oceaninformatics.com
Consultant - IRIS GP Accounts
Member of BCS Primary Health Care Specialist Group – www.phcsg.org
Ian McNicoll wrote:
While you are looking at the regex rules, could you revisit the way that
'any specialisation of' is handled with respect to version numbers?
That's a separate issue really, Ian, more to do with particular tools.
There's already a change request for the Ocean Archetype Editor to do this,
in response to a suggestion by Adam Flinton.
SPEC-260 is about the specification, not about how particular tools use the
specification.
- Peter
Hi Ian
From the spec, a specialised archetype knows what its parent is. If we specify a specialised archetype then we know what parent we are talking about.
What you are suggesting is that we take all specialisations of a particular parent which cannot be determined from the ID at the moment and asking should this be in the ID?
The answer has to be that the specialised archetype must be a specialisation of the parent and for the moment that means looking inside the archetype (ie the regex is not sufficient in itself to guarantee that the parent is not another version).
Worth the techies getting their heads around.
Cheers, Sam
Oops, Ian and Sam, looks like I misinterpreted Ian’s question. I retract my earlier reply
Yes, this is an interesting question Ian!
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:
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:
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:
Thomas Beale wrote:
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_NAMEdomain_concept: concept_name { ‘-’ specialisation }
concept_name: V_NAME
specialisation: V_NAMEversion_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}
This all looks correct to me now, Thomas, except for the version_id
production rule:
‘v’ V_NONZERO_DIGIT [ V_NUMBER ] [ ‘.’ V_NUMBER [ ‘.’ V_NUMBER ] ]
I considered but rejected this idea, because it permits amputated version
numbers such as these:
v1.
v1..
v1..1
v1.1.
I abandoned the "V_NUMBER" idea because it allows the two optional suffixes
to have no digits! You could of course fix that by redefining V_NUMBER like
so:
V_NUMBER: [0-9]+
But then it would force you to start with a two-digit version number. v1, v2
through to v9 would all be illegal versions. Not good!
My solution is a bit tedious, but at least it is (I believe) correct:
'v' V_NONZERO_DIGIT { V_DIGIT } [ '.' V_DIGIT { V_DIGIT } ] [ '.' V_DIGIT
{ V_DIGIT } ]
V_DIGIT: [0-9]
V_NONZERO_DIGIT: [1-9]
Or, if you prefer to nest the second optional part, you could do this:
'v' V_NONZERO_DIGIT { V_DIGIT } [ '.' V_DIGIT { V_DIGIT } [ '.' V_DIGIT {
V_DIGIT } ] ]
Both are correct, but I personally find the flattened out rule a bit easier
to read.
Can someone think of something simpler that is still correct?
- Peter
Sam Heard wrote:
... 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.
In that case the production rule would be simpler:
'v' V_NONZERO_DIGIT { V_DIGIT } [ '.' V_DIGIT { V_DIGIT } ]
V_DIGIT: [0-9]
V_NONZERO_DIGIT: [1-9]
And the version_id part of the regex would be simpler too:
v[1-9]\d*(\.\d+)?
- Peter
Peter Gummer wrote:
Thomas Beale wrote:
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_NAMEdomain_concept: concept_name { ‘-’ specialisation }
concept_name: V_NAME
specialisation: V_NAMEversion_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}
This all looks correct to me now, Thomas, except for the version_id
production rule:‘v’ V_NONZERO_DIGIT [ V_NUMBER ] [ ‘.’ V_NUMBER [ ‘.’ V_NUMBER ] ]
I considered but rejected this idea, because it permits amputated version
numbers such as these:v1.
v1..
v1..1
v1.1.I abandoned the "V_NUMBER" idea because it allows the two optional suffixes
to have no digits! You could of course fix that by redefining V_NUMBER like
so:V_NUMBER: [0-9]+
But then it would force you to start with a two-digit version number. v1, v2
through to v9 would all be illegal versions. Not good!
*The following permits v1, etc, since in **V_NONZERO_DIGIT [ V_NUMBER ]
the latter part is optional.*
Hi Sam,
I agree that the revision number should not be part of the id, from my
view this is unnecessary and only complicates the handling of archetypes.
It may be a good idea to have this information somewhere in the
description section of the archetype though - something that can be
added automatically by the archetype repository for example. For this
some signing /integrity mechanism could be added too if required
Cheers
Sebastian
Sam Heard wrote:
Thomas Beale wrote:
*The following permits v1, etc, since in **V_NONZERO_DIGIT [ V_NUMBER ]
the latter part is optional.*
*
version_id: ‘v’ V_NONZERO_DIGIT [ V_NUMBER ] [ ‘.’ V_NUMBER [ ‘.’
V_NUMBER ] ]V_NONZERO_DIGIT: [1-9]
V_NUMBER: [0-9]+
Ah yes, good point.
This all looks correct to me then.
- Peter
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:
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....
Regards,
Colin