Dear all I am coming back to this issue of interpreting and following Archetype Slots with a simple (i hope) question.
How are we supposed to handle cyclic references created by Archetype Slots? There are quite a few places where cycles might come up, first of all, getting the RM from the AM, building the GUI and finally even up to the complex issue of creating and executing queries. As we clarified earlier there are mainly two flavours of slot binding: a) Formal, b) Recommendation My understanding of the "Formal" slot binding is that the slot would have to be filled explicitly by one of the archetypes that are determined by the include / exclude criteria. In most of the cases of the archetypes that are available through the CKM*, the formal binding does not lead to any cycle formation. However, it is much easier to create cycles with a "Recommendation" type. For example, i can specify something like this: A->B->A That is, [...an archetype (of some kind A) including a slot that accepts a generic archetype (of some kind B) including a slot that can accept...]* And that's the shortest cycle that would create a problem...It is of course possible that longer cycles could emerge unknowingly to authors as the archetype creation process proceeds by various teams independently. Therefore, what i would like to ask is the following: 1) Is there a recommendation for avoiding cycles? (For example, one could say that "you can't attach an archetype of the same or higher level (of datatype) to a slot". In this way, a CLUSTER would only be allowed to reference ELEMENTs. This is guaranteed to lead to a tree but reduces the flexibility of the model) 2) Is this kind of reference something to be expected when modelling clinical data? (In other words, it's actually a use case and you can't prohibit it, so you have to watch for it) 3) While creating the RM / GUI / other artifact, am i expected to follow all links exhaustively in order to create a Tree through which i would first detect cycles, resolve them and THEN create the final version of the RM? (Please note, "fudging" this, by resolving slots lazily is not an option :-). For example, i could create a GUI with all available information and a "Fill This Slot" button at the slot. Once you click the button another form is created which collects the data for the attached archetype. In this case, the algorithm did not hit a "loop" but the user eventually will because "new buttons" for filling in data will keep coming up in new forms.) Looking forward to hearing from you Athanasios Anastasiou *: My XML parser (built out of the openEHR XSDs) kept complaining about the structure of a few XML files downloaded from the CKM, therefore, it was not possible to include all of them to this "cycles" investigation. On 12/04/2012 17:44, Thomas Beale wrote: > On 12/04/2012 17:20, Athanasios Anastasiou wrote: >> >>> BTW, these lexical rules are historical, and will be obsoleted one day - >>> I more or less had to construct them after 100s of archetypes that >>> actually assume these rules had been built! You will see further down in >>> the ADL 1.5 text an indication of the future, but for today, we are >>> stuck with the above... >> Oh joy. (Yes, i did notice that part in the text, it will make the >> constraint more strict but inserts yet more parsing). >> >> Is there a single BNF description of ADL 1.5 available from somewhere? >> * >> * > > yep, they are here > <http://www.openehr.org/wiki/pages/viewpage.action?pageId=196633#openEHRADL%26AOM1.5-TemplatesandSpecialisedArchetypes-Parsergrammars> > - fairly standard .y and .l files. > > - thomas
