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
