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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061122/02315a40/attachment.html>
-------------- next part --------------
_______________________________________________
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
