It is an implementation issue, not a modelling issue.
On Mon, May 12, 2014 at 11:07 AM, Bert Verhees <bert.verhees at rosa.nl> wrote:
> Hi,
>
> I found a peculiarity which causes me some trouble. Not that my trouble is
> a problem, I can solve that, but not without breaking some rules, and the
> solutions is quite arbitrarily.
> The solution is to check if there is any cyclic recursive going on and
> break at a certain arbitrary moment. But it is not a nice solution.
>
> How many times do we see an archetype with an ELEMENT with DV_TEXT matches
> {*} in it?
> So, there are almost no constraints at all on that value.
>
> Condition: The validator always needs to check the parents of a node to
> find its (parents) attributes, because, the parents-attributes are legal
> attributes.
> So, in a non-constrained DV_CODED_TEXT, the attributes of DV_TEXT are
> valid.
>
> In DV_TEXT a legal attribute is mappings->TERM_MAPPING (because there are
> no constraints defined), it is legal to use the mappings-attribute.
> In TERM_MAPPING, there is attribute: purpose-> DV_CODED_TEXT,
> DV_CODED_TEXT inherits from DV_TEXT, and there is our cycle.
>
> So it is possible to bring every OpenEHR-kernel to its knees, and crash
> the system if this is the case.
>
> This is a situation which can of course be triggered by an evil person.
> But mere likely, by an automated feeding system which breaks no rules.
>
> I wonder, shouldn't it be necessary to have something in the Reference
> Model to avoid this situation?
>
> Thanks for any suggestion.
> Bert
>
>
>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>
--
============================================
Timothy Cook
LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook
MLHIM http://www.mlhim.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140512/57dc7b13/attachment.html>
