Well, isn't that the same case that having nesting Sections or
Clusters? I think the way specialization is made in openEHR makes this
a similar issue. However, in your original case I cannot imagine the
use case (or how would work) the automated feeding system you propose.
I would say that instances have fixed size, so even if you have to
process tons of cycles you can assure the process will end (the
instances are finite).
But probably I just don't understand well how the supposed malicious
system works
2014-05-12 16:07 GMT+02:00 Bert Verhees <bert.verhees at rosa.nl>:
> 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
