Pieter, Borat, Pablo, Thomas, Sebastien, …
I e-mailed Thomas, yesterday, but should maybe say it here, too. I’m so impressed with your recent combined and coordinated effort. Thank you. A veritable trio/quartet/quintet/ … of string musicians tuning up - music to my ears in the orchestration of openEHR! 
David
3 Likes
Thanks for your kind words David!
I did some more changes:
- Archie used RULE_SECTION instead of LIST in json. Has been fixed, of course it parses both formats for easy migration.
- the op_ prefix in OperatorKind is also configurable now in serialization, again it parses both formats.
- renamed RULE_STATEMENT to STATEMENT in json (probably never used directly?)
- added some more tests
Review with co-worker should happen next week, but feel free to add a review to the github pull request.
1 Like
Is RULE_SECTION something like RULE_GROUP, conceptually in your implem?
No, just a representation of the entire rules section of the archetype. I have no idea why I introduced that part.
This thread started with a question for ASSERTION in “openehr_expression_104.bmm”.
Many other things were achieved through the discussion - an updated version of Archie, small fixes to BMMs, an agreement to work out a solution for the EL spec.
I also got the ASSERTION (and EXPR_… and OPT2 JSON converter) working. Here is how a generated OPT2 model class for an ARCHETYPE_SLOT looks using the ASSERTION constraint:
…and here is a COMPOSITION class (Vital signs OPT):
Thank you Pieter and Thomas for helping me figure this out.
p.s.
@pieterbos While generating constraints for the attributes I noticed our OPT2 JSON differ for C_ATTRIBUTE_TUPLEs. After your JSON update lands in the VSCode extension I’ll use your JSON to test if it is only visually different from mine or are there also structural differences to what the AM’s OPERATIONAL_TEMPLATE expects.
Tuples (and constraints in general) take many lines to express in the JSON format. Here is an example of a generated tuple constraint for temperature (much shorter ):
…and for height in cm or inches:
…and for blood pressure (no tuples):
1 Like
I’m just getting back to looking at this again. I see there are changes on branches in Archie, but am not sure of where you got to finally on this. Any chance you could make a new bullet point list of differences between the 1.0.4 spec (as it is now) and what you have in the code (today) - I assume this will be a shorter list than before. Then I’ll know what to concretely fix on the spec side.
The way I have done this in the new EL grammar is to treat for_all and there_exists as Boolean leaf objects rather than binary operator, i.e.:
//
// Atomic Boolean-valued expression elements
//
booleanLeaf:
booleanValue
| forAllExpr
| thereExistsExpr
| '(' booleanExpr ')'
| constraintExpr
| SYM_DEFINED '(' valueRef ')'
| arithmeticComparisonExpr
| objectComparisonExpr
| valueRef
;
//
// Universal and existential quantifier
//
forAllExpr: SYM_FOR_ALL localVariableId ':' valueRef '|' booleanExpr ;
thereExistsExpr: SYM_THERE_EXISTS localVariableId ':' valueRef '|' booleanExpr ;
In the next generation object model (BMM) they don’t need matching objects, because for_all is really just syntax for calling a function for_all (lambda(v:T) {expr with v}: Boolean) on a Container type (List, Set etc). I.e. it resolves to a function call that is assumed to exist by the expression compiler.
In the old EL that we have in ADL/AOM2 there is no support for lambdas as such so it might be easier to support for_all and there_exists with model classes that will enable these expressions to be evaluated independently from container types.
1 Like
Another cosmetic change we should make is that EXPR_FUNCTION should have been called EXPR_FUNCTION_CALL, which is what it really stands for, and as far as I can see from the Archie code, how it is understood.
Archie with the mentioned JSON changes in this thread was released last week.
1 Like
I think this must be some intermediate form of model - I couldn’t find this in the currently published version, and it is not in the UML.
I had a look at the Archie code - I have modified the rules part of the AOM a bit (the inheritance was wrong, for one thing), but I might leave this class in, if we can consider the Archie implementation to be a reasonable interpretation / simplification.
I couldn’t find this, but I simplified the Operation definitions part of the model. Archie has an enum that I can’t easily replicate in UML (Java’s enums are more sophisticated than UML’s…)
I have now added a for_all operator to the model, in the same place as you have it in Archie. Naming slightly different to be a a bit clearer, but since there are already other minor naming differences, I don’t think this makes any difference.
Note: you don’t have a there_exists operator in Archie, so I didn’t add one, but it would be easy if needed.
I believe this version of the model is a pretty good match to the Archie implementation.
EDIT: sorry, meant to link it → see here.
1 Like
A bit related to original posts, and to follow up above (although it is hard to tell exactly …):
I recently notice that the ASSERTION class definition is gone from specs (only the BMM_ASSERTION remained). The AOM 2.0.6 UML still refers to it (see diagram for P_ARCHETYPE_SLOT at Archetype Object Model 2 (AOM2)) but in the latest is not (see same P_ARCHETYPE_SLOT' on diagram at Archetype Object Model 2 (AOM2)).
I suspect this UML issue is related to all discussion above - I just wonder what would be the fix, and where is the ASSERTION class nowadays.
For reference:
1 Like