On 12/05/2014 22:20, Bert Verhees wrote:
> Thomas Beale schreef op 12-5-2014 17:25:
>> I don't see the problem here; the DV_CODED_TEXT of the
>> TERM_MAPPING.purpose is always a different instance from the root
>> DV_TEXT or DV_CODED_TEXT instance. So how can a loop occur?
> What I was doing was writing validation-rules for: DV_TEXT matches{*}
> I am working on the finishing part of software to write
> validation-rules automated, archetypes are translated to
> validation-rules, and I am doing the last bits, so I came to this
> which I had saved in a TODO list.
> I had a stack-overflow, and first I thought it was a bug, but after
> investigating, I found, it was as designed.
>
> For this situation, I had to write a rule for attribute: mappings,
> which can be used, because there is no constraint.
> And I wanted to validate the expression completely, so every possible
> attribute had to be handled, with occurrence as defined in the
> XML-Schema. Attribute: mappings is optional, so it is allowed.
> Every attribute that is not a simple type, but a complex OpenEHR-type
> needs to be treated the same way (recursive), so in the
> mappings-attribute, there is the purpose-attribute which again can
> have a mappings-attribute, which again can have purpose-attribute, and
> so on.
>
> A data-set which would look like that recursive situation would still
> match inside the archetype-definition.
> Even if this would repeat ten times inside that data-set, it would
> still be matching against the archetype.
this bit is true. Do you have such pathological data? The easiest way I
think of dealing with this would be to add a counter for how many times
a particular type has been traversed in any tree descent, and stop if it
goes over some settable limit like 100.
>
> I admit that the problem is a theoretical one, and I suggested an
> automated feeding system, which could create that to make it less
> theoretical.
> I have seen systems which go to every detail and every bit, thinkable,
> automated systems sometimes go very deep.
>
> The problem is, how can validation software distinguish erroneous
> nesting from legitimate nesting.
> I don't think that is possible, so the validating software has to stop
> at a certain arbitrary level of depth.
> At a certain point, the validating software will mark a part of a
> data-set as erroneous: "too deeply nested", even if it still fits
> inside the archetype
Agree - set an arbitrary (deep) limit.
>
> Then I remembered a teacher from years ago, he said: Don't write
> perfect software, write feasible software
>
> But OK, thank you all for your reply's, I am now convinced that it is
> not a 100% solvable problem.
well it's solvable in a heuristic / ad hoc way...
- thomas
