From: openEHR-technical <openehr-technical-boun...@lists.openehr.org> on behalf of Thomas Beale <thomas.be...@openehr.org> Reply-To: For openEHR technical discussions <openehr-technical@lists.openehr.org> Date: Saturday, 2 February 2019 at 20:10 To: "openehr-technical@lists.openehr.org" <openehr-technical@lists.openehr.org> Subject: Re: Rules in archetypes - what are the requirements?
On 02/02/2019 16:21, Pieter Bos wrote: From: openEHR-technical <openehr-technical-boun...@lists.openehr.org><mailto:openehr-technical-boun...@lists.openehr.org> on behalf of Thomas Beale <thomas.be...@openehr.org><mailto:thomas.be...@openehr.org> Reply-To: For openEHR technical discussions <openehr-technical@lists.openehr.org><mailto:openehr-technical@lists.openehr.org> Date: Saturday, 2 February 2019 at 15:01 To: "openehr-technical@lists.openehr.org"<mailto:openehr-technical@lists.openehr.org> <openehr-technical@lists.openehr.org><mailto:openehr-technical@lists.openehr.org> Subject: Re: Rules in archetypes - what are the requirements? Assuming you meant to put 'id7' as the first one, I don't understand what this achieves beyond just: /events[id2]/data/items/element[id7]/value/magnitude > /events[id2]/data/items/element[id4]/value/magnitude + /events[id2]/data/items/element[id5]/value/magnitude + /events[id2]/data/items/element[id6]/value/magnitude which says the same thing, for all events in the runtime data that conform to the /events[id2] branch of the structure. Since the occurrences of events[id2] can be more than one, /events[id2]/data/items/element[id7]/value/magnitude in the execution environment (actual data) maps to a List<Real>. well it could be understood that way - that would be to literally interpret it as a runtime path. The way I think of it is to mean 'this condition xyz must hold true' for each instance to which it applies. This greatly simplifies things - otherwise you end up in a complicated place like you have described below. If not runtime but archetype paths, eventually you need to apply them to runtime data to evaluate. There are several ways of doing that – one way is what I did in Archie. Another one that I considered was automatically detecting common parent objects with effective_occurrences potentially > 1 and automatically adding for_all, plus some validation – less code, but more complex code. Another one is requiring for_all statements written by the rule modeler/developer (this is not possible in the published draft without your relative path proposal below). There are more ways to do this. Each one will operate differently in different edge cases, if this is not specified. If however you do your ‘this path is relative to the other one’ context binding below, with a for_all that works with these path bindings, I think that should solve most of the problems. the Expression Language draft<https://specifications.openehr.org/releases/LANG/latest/expression_language.html#_defined_predicate> has the defined() predicate which I think should do the job. It should, when combined with the new if-statement that is much more powerful than the implies-statement in the previous version. However, it has some interesting implications when combined with the “'this condition xyz must hold true for each instance to which it applies”-idea specified above if not combined with an explicit for_all. Because also the corresponding defined()-check must be done for each instance. That’s the reason I integrated null-handling as ‘if an assertion/check has a null value, that means it’s missing data required to evaluate it. So the assertions is not relevant, meaning that it passes’. Then you can manually specify exists/defined conditions if you need them. It would still be Real. The idea is that the path is relative to an EVENT, although that is not clear from the above. Perhaps something like: $item_aaa -> (EVENT)/data/items/element[id7]/value/magnitude That would solve it. That would solve the problem. Why not just inline the assignments, such as: $events := /events[id2] this was in a previous draft. But I am pretty convinced we don't want to mix paths in with the main 'code'. This is particularly the case if we want to use TypeScript or some other mainstream language to write the main statements in - the bindings need to be separate. I'll have more of a think about how the bindings should work. If typescript/javascript (typescript compiles to javascript before execution), that will change quite a lot about the discussion before. Since a path query is just a string, it’s not so hard to create an (included) path lookup function and an ‘assign value to this path’ function. Regards, Pieter Bos
_______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
