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
_______________________________________________
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
