Hi,
I have noticed that instruction archetypes have different ways of adding constraints on archetype IDs and domain concepts. Here’s an example:
INSTRUCTION[at0000] matches { – Imaging request
activities cardinality matches {0..; unordered} matches {
ACTIVITY[at0001] occurrences matches {1..} matches { – Imaging activity
action_archetype_id matches {“/imaging.v1/”}
description matches {
allow_archetype ITEM_TREE occurrences matches {0..1} matches {
include
domain_concept matches {/imaging.v1/}
exclude
domain_concept matches {/.*/}
}
}
}
}
}
As you can see for the action_archetype_id the leaf constraint is “/imaging.v1/” which will correspond to a C_STRING. However, since we have the
quotation marks the Eiffel parser will probably just add /imaging.v1/ into the list of the C_STRING (the Java parser will not even parse this, and fails when it detects the escape character, i.e. \ ).
What I think we want to achieve here is to set the pattern attribute of C_STRING. Here’s a description of the pattern attribute:
pattern: String Regular expression pattern for proposed instances of String to match.
Now to do this we must remove the quotation marks which gives us:
/imaging.v1/ which works in the Java parser and sets the pattern attribute of the CString class.
Now the leaf constraint of action_archetype_id will be more similar to the archetype slot includes and excludes. However, you will see one difference. In the include slot (/imaging.v1/) the dot is not escaped, which in regular expressions means it will match any character and not just the dot, for example an archetype with the domain concept imagingav1 would be perfectly legal.
Another issue is whether action_archetype_id should have a regular expression that matches a domain concept (for any kind of archetype) or if the regular expression in this case actually should be extended to /openEHR-EHR-ACTION.imaging.v1/ ? I think it would be good if the regex always started with openEHR-EHR-ACTION in this case, but maybe the distinction can be made when the rm objects are built…
Hope to sort this out.
Regards,
Mattias
Mattias Forss wrote:
Hi,
I have noticed that instruction archetypes have different ways of
adding constraints on archetype IDs and domain concepts. Here's an
example:
INSTRUCTION[at0000] matches { -- Imaging request
activities cardinality matches {0..*; unordered} matches {
ACTIVITY[at0001] occurrences matches {1..*} matches {
-- Imaging activity
action_archetype_id matches {"/imaging\.v1/"}
description matches {
allow_archetype ITEM_TREE occurrences matches
{0..1} matches {
include
domain_concept matches {/imaging.v1/}
exclude
domain_concept matches {/.*/}
}
}
}
}
}
As you can see for the action_archetype_id the leaf constraint is
"/imaging\.v1/" which will correspond to a C_STRING. However, since we
have the
quotation marks the Eiffel parser will probably just add /imaging\.v1/
into the list of the C_STRING (the Java parser will not even parse
this, and fails when it detects the escape character, i.e. \ ).
having "" outside of // is definitely and error, and will do exactly
what you say.
What I think we want to achieve here is to set the pattern attribute
of C_STRING. Here's a description of the pattern attribute:
pattern: String Regular expression pattern for proposed instances of
String to match.
Now to do this we must remove the quotation marks which gives us:
/imaging\.v1/ which works in the Java parser and sets the pattern
attribute of the CString class.
Now the leaf constraint of action_archetype_id will be more similar to
the archetype slot includes and excludes. However, you will see one
difference. In the include slot (/imaging.v1/) the dot is not escaped,
which in regular expressions means it will match any character and not
just the dot, for example an archetype with the domain concept
imagingav1 would be perfectly legal.
also true, but probably unintended in an archetype id matching expression.
Another issue is whether action_archetype_id should have a regular
expression that matches a domain concept (for any kind of archetype)
or if the regular expression in this case actually should be extended
to /openEHR-EHR-ACTION\.imaging\.v1/ ? I think it would be good if the
regex always started with openEHR-EHR-ACTION in this case, but maybe
the distinction can be made when the rm objects are built...
I would agree with you here as well Mattias. Will add some notes to the
todo list for the tools 
- thomas