Hello everyone If it is any more help, here is an earlier discussion on cyclic references:
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/2012q2/007015.html I think that the ADL 1.5 modifications took care of this discrepancy at the model level as well. All the best Athanasios Anastasiou On 12/05/2014 16:47, Grahame Grieve wrote: > 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 > <mailto: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 > <mailto:openEHR-technical at lists.openehr.org> > > http://lists.openehr.org/__mailman/listinfo/openehr-__technical_lists.openehr.org > > <http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org> > > > > > -- > ----- > http://www.healthintersections.com.au / > grahame at healthintersections.com.au > <mailto:grahame at healthintersections.com.au> / +61 411 867 065 > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >
