If the value is not constrained, the validator should return true without
continuing checking in cascade-recursive mode. For this to work as expected,
the data structure should be validated before than the data validation. The
easiest way of validating the structure is serializing the instance to XML and
using XSD.
Sent from my LG Mobile
Bert Verhees <bert.verhees at rosa.nl> 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.
>
>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
>
>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.
>
>
>best regards
>Bert
>
>_______________________________________________
>openEHR-technical mailing list
>openEHR-technical at lists.openehr.org
>http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
