Hi Bert,
On 12/05/2014 15:07, Bert Verhees 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?
BTW, in ADL 1.5, this is no longer used, the constraint could just be
something like
attr matches {
DV_TEXT
}
if there are no other constraints at all. The semantics are the same
however, so it doesn't change your question.
> 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.
the right way to see this is that the validator needs to be using the
(inheritance-)flattened form of the node, as is available in the
flattened template.
>
> 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.
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? Are you
saying that it could due to buggy software or data? But that's the same
possibility for any data processing framework where a type T has a
property p of type V with a property q of type T... I have to agree with
Tim here, this is probably just about implementation quality.
- thomas
