there's usually edge cases in validation where you can stack crash if
you're not really careful (been there many times). That doesn't mean that
the specs are wrong, but if you can clearly describe the case, it might be
worth documenting the risks around it
Grahame
On Tue, May 13, 2014 at 1:25 AM, Thomas Beale <
thomas.beale at oceaninformatics.com> wrote:
>
> 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
>
>
>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>
--
-----
http://www.healthintersections.com.au /
grahame at healthintersections.com.au/ +61 411 867 065
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140513/9f586029/attachment.html>
