# ASSERTION in openehr_expression_104.bmm is not in accordance with the specifications **Category:** [BMM/Expressions](https://discourse.openehr.org/c/bmm-el/60) **Created:** 2021-12-16 10:29 UTC **Views:** 1640 **Replies:** 53 **URL:** https://discourse.openehr.org/t/assertion-in-openehr-expression-104-bmm-is-not-in-accordance-with-the-specifications/2203 --- ## Post #1 by @borut.jures The definition of ASSERTION in "openehr_expression_104.bmm" is not in accordance with the specifications. ASSERTION Class is specified in: - [ASSERTION Class in AM 2.0.6/AOM1.4](https://specifications.openehr.org/releases/AM/Release-2.0.6/AOM1.4.html#_assertion_class) - [ASSERTION class in BASE 1.0.4](https://specifications.openehr.org/releases/BASE/Release-1.0.4/expression.html#_assertion_class) The specifications are not the same (inherits, variables). I guess the one in BASE is the correct one when used with AOM 2.0.6. The BMM file for the ASSERTION is missing: - string_expression - expression I looked at Archie's version of the AM 2.0.6 BMM file and it contains the ASSERTION class that is modeled as [ASSERTION Class in AM 2.0.6/AOM1.4](https://specifications.openehr.org/releases/AM/Release-2.0.6/AOM1.4.html#_assertion_class) with some differences: - it has "variables" - it has "tag" as "is_mandatory" (it should be optional) - it has "string_expression" as "is_mandatory" (it should be optional) - it inherits from RULE_STATEMENT instead of STATEMENT) I changed the ASSERTION in "openehr_expression_104.bmm": ``` -- ["ASSERTION"] = < -- name = <"ASSERTION"> -- ancestors = <"STATEMENT"> -- properties = < -- ["tag"] = (P_BMM_SINGLE_PROPERTY) < -- name = <"tag"> -- type = <"String"> -- > -- > -- > ["ASSERTION"] = (P_BMM_CLASS) < name = <"ASSERTION"> ancestors = <"STATEMENT"> properties = < ["tag"] = (P_BMM_SINGLE_PROPERTY) < name = <"tag"> type_def = < type = <"String"> > > ["string_expression"] = (P_BMM_SINGLE_PROPERTY) < name = <"string_expression"> type_def = < type = <"String"> > is_mandatory = > ["expression"] = (P_BMM_SINGLE_PROPERTY) < name = <"expression"> type_def = < type = <"EXPRESSION"> > is_mandatory = > > > ``` --- @pieterbos In OPT2 JSON generated with Nedap's VSCode extension I had to: - replace "BINARY_OPERATOR" with "EXPR_BINARY_OPERATOR" --- ## Post #2 by @borut.jures The "EXPR_..." types are also missing properties in “openehr_expression_104.bmm”. OPT2 JSON is missing "EXPR_" prefix for the other "expression" types too. I wish all the OPTs were using AM >= 2.1.0 and RM >= 1.1.0 :blush: --- ## Post #3 by @pieterbos Sorry, we haven't done much interoperability with the assertions section. It will need some work in archie to get the EXPR_ added again for the classes that do exists, to get all the class names correct., plus the other fixes. I do not have time to do that soon, I hope to have a bit more time next year to fix this. --- ## Post #4 by @thomas.beale [quote="borut.jures, post:1, topic:2203"] The BMM file for the ASSERTION is missing: * string_expression * expression [/quote] Now fixed in ITS-BMM - thanks for the report! --- ## Post #5 by @borut.jures [quote="thomas.beale, post:4, topic:2203"] Now fixed in ITS-BMM - thanks for the report! [/quote] Thank you for the quick fix. [quote="borut.jures, post:2, topic:2203"] The “EXPR_…” types are also missing properties in “openehr_expression_104.bmm”. [/quote] I guess the above comment was missed. Here is a longer version :sweat_smile: May I ask for these to be updated too please :blush: p.s. I'm putting these BMMs to good use. I can already generate JSON for a COMPOSITION with all the necessary code generated based on the BMM files. Soon any web developer will be able to build an openEHR app without knowing anything about AM/RM. A little scary but this is what they asked for. Technicaly it will be a big win for computable specifications. # [VARIABLE_DECLARATION](https://specifications.openehr.org/releases/BASE/Release-1.0.4/expression.html#_variable_declaration_class): - "type" should have "is_mandatory=true" # [ASSIGNMENT](https://specifications.openehr.org/releases/BASE/Release-1.0.4/expression.html#_assignment_class): - "target" should have "is_mandatory=true" - "source" should have "is_mandatory=true" # [EXPR_OPERATOR](https://specifications.openehr.org/releases/BASE/Release-1.0.4/expression.html#_expr_operator_class): - missing "operator_def: OPERATOR_DEF" with "is_mandatory=true" # [EXPR_UNARY_OPERATOR](https://specifications.openehr.org/releases/BASE/Release-1.0.4/expression.html#_expr_unary_operator_class): - missing "operand: EXPRESSION" with "is_mandatory=true" # [EXPR_BINARY_OPERATOR](https://specifications.openehr.org/releases/BASE/Release-1.0.4/expression.html#_expr_binary_operator_class): - missing "left_operand: EXPRESSION" with "is_mandatory=true" - missing "right_operand: EXPRESSION" with "is_mandatory=true" # [OPERATOR_DEF](https://specifications.openehr.org/releases/BASE/Release-1.0.4/expression.html#_operator_def_class): - missing class # [OPERATOR_DEF_BUILTIN](https://specifications.openehr.org/releases/BASE/Release-1.0.4/expression.html#_operator_def_builtin_class): - missing class # [BUILTIN_OPERATORS](https://specifications.openehr.org/releases/BASE/Release-1.0.4/expression.html#_builtin_operators_class): - missing class # [EXPR_LITERAL](https://specifications.openehr.org/releases/BASE/Release-1.0.4/expression.html#_expr_literal_class): - "item" should have "is_mandatory=true" # [EXPR_VARIABLE_REF](https://specifications.openehr.org/releases/BASE/Release-1.0.4/expression.html#_expr_variable_ref_class): - "item" should have "is_mandatory=true" # [EXPR_FUNCTION](https://specifications.openehr.org/releases/BASE/Release-1.0.4/expression.html#_expr_function_class): - missing "arguments" - missing "function_def" with "is_mandatory=true" # [FUNCTION_DEF](https://specifications.openehr.org/releases/BASE/Release-1.0.4/expression.html#_function_def_class): - missing class # [FUNCTION_DEF_BUILTIN](https://specifications.openehr.org/releases/BASE/Release-1.0.4/expression.html#_function_def_builtin_class): - missing class # [BUILTIN_FUNCTIONS](https://specifications.openehr.org/releases/BASE/Release-1.0.4/expression.html#_builtin_functions_class): - missing class # [EXPR_TYPE_DEF](https://specifications.openehr.org/releases/BASE/Release-1.0.4/expression.html#_expr_type_def_class): - missing "type_name" with "is_mandatory=true" - missing "type_anchor" with "is_mandatory=true" - other classes in [4.4. Typing](https://specifications.openehr.org/releases/BASE/Release-1.0.4/expression.html#_typing_2) are missing # [4.3. Extension Package](https://specifications.openehr.org/releases/BASE/Release-1.0.4/expression.html#_extension_package): - these classes are missing too (I'm not sure I've seen them used in OPTs) --- ## Post #6 by @thomas.beale I've made changes to the Expression 1.0.4 BMM; it doesn't include the extension classes, but it includes everything else and compiles in ADL Workbench. NB: this version of the expression language is old, incomplete, contains some logical errors and will not be supported in the future - so I would suggest to not create any new work based on it. --- ## Post #7 by @borut.jures Thank you! One small correction is needed: - ASSERTION.expression type should be "EXPRESSION". And I had to add these classes to the "packages" for my validator to be happy: ``` "TYPE_DEF_BOOLEAN", "TYPE_DEF_INTEGER", "TYPE_DEF_REAL", "TYPE_DEF_DATE", "TYPE_DEF_DATE_TIME", "TYPE_DEF_TIME", "TYPE_DEF_DURATION", "TYPE_DEF_STRING", "TYPE_DEF_URI", "TYPE_DEF_TERMINOLOGY_CODE", "TYPE_DEF_OBJECT_REF", "OPERATOR_DEF", "FUNCTION_DEF", "OPERATOR_DEF_BUILTIN", "FUNCTION_DEF_BUILTIN", "BUILTIN_OPERATORS", "BUILTIN_FUNCTIONS" ``` --- @pieterbos I'm struggling with OPT2 JSON definition of "EXPR_BINARY_OPERATOR". Its "left_operand" and "right_operand" should be of type "EXPRESSION" but I found type "MODEL_REFERENCE": ``` "left_operand" : { "@type" : "MODEL_REFERENCE", "precedence_overridden" : false, "path" : "archetype_id/value" }, ``` This type is present in "openEHR_aom_206-generated.bmm" but I don't find it in the standard AM. The closest one is "EXPR_LITERAL" but with attribute "item" instead of "path" (path is mentioned in the description of [EXPR_LEAF](https://specifications.openehr.org/releases/BASE/Release-1.0.4/expression.html#_expr_leaf_class) but never used as an attribute name). It is too late too finish this tonight (and maybe I get a hint from somebody). --- ## Post #8 by @borut.jures This is an example of ASSERTION that doesn't look right to me (scroll to see everything): ```json "includes" : [ { "@type" : "ASSERTION", "string_expression" : "archetype_id/valuematches{/.*/}", "expression" : { "@type" : "BINARY_OPERATOR", "type" : "BOOLEAN", "precedence_overridden" : false, "operator" : "matches", "right_operand" : { "@type" : "CONSTRAINT", "precedence_overridden" : false, "item" : { "@type" : "C_STRING", "rm_type_name" : "string", "node_id" : "id9999", "constraint" : [ "/.*/" ], "logical_path" : "/", "allowed" : true, "required" : false, "prohibited" : false, "attributes" : [ ], "path" : "/" } }, "left_operand" : { "@type" : "MODEL_REFERENCE", "precedence_overridden" : false, "path" : "archetype_id/value" }, "unary" : false }, "variables" : [ ] } ], ``` [quote="thomas.beale, post:6, topic:2203"] NB: this version of the expression language is old, incomplete, contains some logical errors and will not be supported in the future - so I would suggest to not create any new work based on it. [/quote] @pieterbos Was this a solution to get something working with AM 2.0.6 and “openehr_expression_104.bmm” and it doesn't conform to the specifications? Or am I missing something? @thomas.beale Are there any OPT2s for AM >= 2.1.0 that you are aware of? --- ## Post #9 by @pieterbos The implementation in Archie of the expression language is what was defined in the standard at the time, which was implemented because we needed a standard way to write the rules section and this was specified in 2.0.6. Thomas then changed the standard, assuming it wasn't in use. It had at least two implementations, one in ADL 2 and one in ADL 1.4, so the specification was put back in place as good as was possible. So the object model in Archie could be a near match rather than an exact one. So while it is 'old', it is also the only standard that is implemented to express rules in archetypes. Thomas wants something new, but there is still ongoing debate over what it should be. Personally I think it should perhaps be something existing and really not something openehr specific, especially if it is to have more features than the current mini-language. The Model reference is to express a path in the rules language, so /data[id3]/something would be a model reference. This was following the object model specification at that point in time, and is an expression sub-type. It is apparently called EXPR_ARCHETYPE_REF in the current sspecification, defined here: https://specifications.openehr.org/releases/AM/Release-2.2.0/AOM2.html#_expr_archetype_ref_class. the Archie implementation contains a variable prefix as an addition to the path, because that can appear in the language, specifically but not limited to inside for_all statements. --- ## Post #10 by @borut.jures Thank you for the explanation! It makes sense. Real life implementations usually move faster than specifications. I learned that there are no standard expression models/grammars. In my latest project before I started with openEHR, I wrote an ANTLR4 grammar for an existing programming language. I looked at [popular languages](https://github.com/antlr/grammars-v4) and realized they all use different grammars for the expressions. @thomas.beale The mentioned EXPR_ARCHETYPE_REF is missing in AM 2.1.0 and 2.2.0 BMM files. --- It looks to me that when ARCHETYPE_SLOT is reached the pattern of attributes/children isn't followed anymore and a custom structure is used for ARCHETYPE_SLOT and ASSERTION :thinking: I'll try to work with that or I'll have to write an OPT2 parser :sweat_smile: @thomas.beale Should I use [the new grammars](https://github.com/wolandscat/openEHR-antlr4) if I decide to write the OPT2 parser? --- ## Post #11 by @thomas.beale [quote="pieterbos, post:9, topic:2203"] The implementation in Archie of the expression language is what was defined in the standard at the time, which was implemented because we needed a standard way to write the rules section and this was specified in 2.0.6. [/quote] Just to be clear - it was just a draft i.e. in development - there was never any release - that's why we have created this BASE 1.0.4 release retrospectively. ([Here's the last commit to BASE](https://github.com/openEHR/specifications-BASE/tree/e17d332fa6a756a0f1f5add5f269cc2f82030528) that contained the old Expression language, before we inserted the 1.0.4 branch; within this, the [Expression language spec was in DEVELOPMENT phase](https://raw.githubusercontent.com/openEHR/specifications-BASE/e17d332fa6a756a0f1f5add5f269cc2f82030528/docs/expression/master.adoc)). [quote="pieterbos, post:9, topic:2203"] Thomas then changed the standard, assuming it wasn’t in use. [/quote] well - development on the draft spec just continued. I wouldn't want anyone to think we don't have reliable release and versioning processes - we do, but we didn't use them here. It may have also been the case that the specifications development lifecycle was not as obvious as it should be - for the record it is [documented here](https://www.openehr.org/programs/specification/changeprocess). [quote="pieterbos, post:9, topic:2203"] It had at least two implementations, one in ADL 2 and one in ADL 1.4, so the specification was put back in place as good as was possible. [/quote] yes - unfortunately, I didn't know this. If I had, I would have suggested to the SEC to agree on a releasable version of this spec, so that implementations were connected to something stable. We have much better communication these days, and I don't think we'll get into this situation again. We've put a fair bit of collective effort into getting this old Expressions spec stabilised retrospectively, so it indeed corresponds as closely as possible to these implementations. It has been somewhat annoying for everyone, but I guess a good lesson on the importance of getting releasing right. [quote="pieterbos, post:9, topic:2203"] Thomas wants something new, but there is still ongoing debate over what it should be. [/quote] well, it's not just some aesthetic preference - this older draft language was never finished, primarily because it contains some design problems. I had not performed a sufficiently full analysis to fix these at the time, so it remained in that state. The new version is: * a) based on a much better analysis (including review of features in various other languages); * b) has made much better use of current Antlr tools (4.9) which significantly improved a lot of details (more than I had expected I must admit); * c) incorporates features that cover the semantics in use by the existing 4 separate expression languages in openEHR (ADL rules; AQL; Task Planning expressions; GDL2) [quote="pieterbos, post:9, topic:2203"] Personally I think it should perhaps be something existing and really not something openehr specific, especially if it is to have more features than the current mini-language. [/quote] Well I and others have had a pretty careful look at doing that. The research project I worked at in Intermountain Healthcare doing advanced workflow looked at various existing languages including Java and TypeScript, and decided they did not do what was needed; they rolled their own expression language and had it running in a couple of weeks. In the Task Planning project, Better went a step further and actually implemented a TypeScript execution container and converted (the relatively simple) expressions from string statements within a Task Plan into a TS internal representation for execution (I suspect via some JSON conversion that was then materialised by the container implementation). This was found to be seriously slow (probably fixable), but also missing some needed operators and features (not fixable). So they also decided to go native. Implementing a language these days is relatively easy - that's one reason there are so many programming languages around. The speed at which a language definition can be developed, tested and implemented is much higher than it used to be. The approach I have taken in more recent times is based on a) a high quality meta-model aka 'enhanced AST' (= [current version of BMM](https://specifications.openehr.org/releases/LANG/latest/bmm.html)) and b) a full syntax implementation (= current [LANG/Expression Language](https://specifications.openehr.org/releases/LANG/latest/expression_language.html)) in Antlr 4.x, to ensure that there is at least one working syntax. The meta-model provides the semantics, as well as the ability to serialise out to other syntaxes / languages. This version of BMM and its associated (new) expression language is pretty generic and when it is completed (mainly the expression syntax part), will at least be a candidate for a common expression and decision language for openEHR. There is nothing stopping other development proposals from being created. At the end, the SEC will need to review and consider what to release for the wider community. Others may have different opinions and approaches - these are all welcome from my point of view. We have the Specifications Editorial Committee to make determinations on a way forward based on what is available at any given time. THis is as it should be I think. BTW: there is a [call-out facility in the new BMM](https://specifications.openehr.org/releases/LANG/latest/bmm.html#_routine_body) to enable a routine (i.e. set of statements / expressions) to be implemented using any language, which will take care of a) re-use of existing code and b) orgs that want to write expressions in current programming languages. This approach won't be highly interoperable for decision logic, Task Planning, GDL3 etc, but it will be useful for other purposes. --- ## Post #12 by @thomas.beale [quote="borut.jures, post:10, topic:2203"] I learned that there are no standard expression models/grammars. In my latest project before I started with openEHR, I wrote an ANTLR4 grammar for an existing programming language. I looked at [popular languages](https://github.com/antlr/grammars-v4) and realized they all use different grammars for the expressions. [/quote] Yes exactly right. The most advanced meta-model I have developed to date is the [current BMM](https://specifications.openehr.org/releases/LANG/latest/bmm.html), which covers expressions but also literals, full routines, classes, lambdas and so on. The [current (incomplete) Expression Language](https://specifications.openehr.org/releases/LANG/latest/expression_language.html) is designed as a syntax for this BMM. I am developing this via Antlr4, which is enabling me to correct both the meta-model and devise a workable syntax. You will notice near the end it has some tabular decision syntax (no if/then statements) as well as other features needed in decision logic. --- ## Post #13 by @thomas.beale [quote="borut.jures, post:7, topic:2203"] * ASSERTION.expression type should be “EXPRESSION”. [/quote] Now fixed. [quote="borut.jures, post:7, topic:2203"] And I had to add these classes to the “packages” for my validator to be happy [/quote] Not sure of the problem there - these classes were in the package class list (the ADL Workbench won't pass the model without them either). However, I did correct the structure to put the types in a sub-package as stated in the spec. --- ## Post #14 by @sebastian.iancu A bit off-topic, but where is this attribute `@type` coming from? (which serializer) [quote="borut.jures, post:8, topic:2203"] `"@type" : "ASSERTION",` [/quote] Is this not rather `_type` ? --- ## Post #15 by @borut.jures [quote="sebastian.iancu, post:14, topic:2203"] where is this attribute `@type` coming from? [/quote] It is from the otherwise very useful Nedap's VSCode extension (thank you @pieterbos for it). I believe they are busy with their production systems and don't have time to update Archie to the current version of the specifications. --- Since my OPERATIONAL_TEMPLATE code for de-serialization from JSON is generated from the specifications it expects OPT2 JSON to exactly follow the specifications. Hence I started writing my own ADL2 to OPT2 JSON converter :blush: --- ## Post #16 by @borut.jures [quote="borut.jures, post:10, topic:2203"] @thomas.beale Should I use [the new grammars](https://github.com/wolandscat/openEHR-antlr4) if I decide to write the OPT2 parser? [/quote] I use the new grammars in [github.com/wolandscat/openEHR-antlr4](https://github.com/wolandscat/openEHR-antlr4) to parse OPT2 files. According to ARCHETYPE_SLOT.includes should be of type ASSERTION. The grammar parses it as DELIMITED_REGEX (the comment mentions ASSERTION from EL but it probably isn't ready yet): ```antlr4 // Slot includes are modelled to support only the simple form of // path matches {regex}, but this is probably safe. If not, the // 'assertion' rule from EL is required, which causes the whole EL // to be sucked in to CADL. archetypeSlot: SYM_ALLOW_ARCHETYPE rmTypeId nodeId (( cOccurrences? ( SYM_MATCHES '{' cIncludes? cExcludes? '}' )? ) | SYM_CLOSED ) ; cIncludes : SYM_INCLUDE archetypeIdConstraint+ ; cExcludes : SYM_EXCLUDE archetypeIdConstraint+ ; archetypeIdConstraint: archetypeIdPath SYM_MATCHES '{' DELIMITED_REGEX '}' ; ``` The "stable" version of CADL grammar uses the EXPRESSION expected by AM 2.0.6: ```antlr4 assertion: variableDeclaration | booleanAssertion; variableDeclaration: VARIABLE_DECLARATION SYM_ASSIGNMENT expression; booleanAssertion: ( identifier SYM_COLON )? expression ; ``` I should probably switch to the stable grammars :thinking: @thomas.beale Unless you wish somebody to test the new ones? :wink: --- ## Post #17 by @borut.jures I switched to [adl-antlr](https://github.com/openEHR/adl-antlr) grammars. The ASSERTION part produces this parse tree: ![assertion-parseTree|690x149](upload://7e3AC4EaQphccmmbYHD4dy9cEkc.png) It doesn't look like any EXPR_ class in AM 2.0.6. AM 2.0.6 has EXPR_BINARY_OPERATOR. It has left_operand and right_operand of type EXPRESSION. Which sub-types should be used based on the parse tree above? Should a BINARY_OPERATOR (that was added to Archie's version of AM 2.0.6) also be added to the official AM 2.0.6? Adding BINARY_OPERATOR would make Archie's OPT2 JSON compatible with AM 2.0.6 and the ASSERTION parse tree could be converted into it. There is a similar [EL_BINARY_OPERATOR](https://specifications.openehr.org/releases/LANG/latest/bmm.html#_el_binary_operator_class) in the latest release. I would like to stick to the official BMMs. Otherwise there will be Archie AM, NeoEHR AM,... ![expression-classes|655x499](upload://2CVoe1IMPr4T2jqoBDEIHsBbXZD.jpeg) --- ## Post #18 by @thomas.beale [quote="borut.jures, post:16, topic:2203"] I use the new grammars in [github.com/wolandscat/openEHR-antlr4](https://github.com/wolandscat/openEHR-antlr4) to parse OPT2 files. [/quote] Unfortunately you'll probably have to wait until Christmas / New year before I get back to those grammars - they are a lot better than the current ones, but the Expression part is a) not finished and b) is the new Expression language, not the AM 2.0.6 one. So if you want stability and sanity, ... you know what to do ;) --- ## Post #19 by @borut.jures [quote="borut.jures, post:17, topic:2203"] AM 2.0.6 has EXPR_BINARY_OPERATOR. It has left_operand and right_operand of type EXPRESSION. Which sub-types should be used [/quote] A report on how I solved the issue of ASSERTION in OPT2 JSON. ASSERTION.expression is of type EXPRESSION. "openehr_expression_104.bmm" has [EXPR_BINARY_OPERATOR](https://specifications.openehr.org/releases/AM/latest/AOM1.4.html#_expr_binary_operator_class). I used this type for the ASSERTION.expression. EXPR_BINARY_OPERATOR has left_operand and right_operand of type EXPRESSION. I used [EXPR_LITERAL](https://specifications.openehr.org/releases/BASE/Release-1.0.4/expression.html#_expr_literal_class) for "left_operand" and "right_operand" (as mentioned by Pieter EXPR_ARCHETYPE_REF and other needed EL_ classes are only found in the unpublished specifications). I used [OPERATOR_DEF_BUILTIN](https://specifications.openehr.org/releases/BASE/Release-1.0.4/expression.html#_operator_def_builtin_class) for the "operator_def". In the end I could use only the standard classes in the "openehr_expression_104.bmm": ```json { "_type": "ASSERTION", "string_expression": "archetype_id/valuematches{/.*/}", "expression": { "_type": "EXPR_BINARY_OPERATOR", "left_operand": { "_type": "EXPR_LITERAL", "item": { "_type": "C_STRING", "rm_type_name": "String", "node_id": "id9999", "constraint": [ "archetype_id/value" ] } }, "operator_def": { "_type": "OPERATOR_DEF_BUILTIN", "identifier": "matches", "op_table": { "op_matches": [ "matches" ] } }, "right_operand": { "_type": "EXPR_LITERAL", "item": { "_type": "C_STRING", "rm_type_name": "String", "node_id": "id9999", "constraint": [ "/.*/" ] } } } } ``` It is similar to [OPT2 JSON produced by Nedap's VS Code extension](https://discourse.openehr.org/t/assertion-in-openehr-expression-104-bmm-is-not-in-accordance-with-the-specifications/2203/8). p.s. Thank you @pieterbos for using C_STRING in your version of OPT2 JSON. I first tried with STRING but couldn't make it work. Then I saw you used C_STRING and that solved it for me too. --- ## Post #20 by @borut.jures Should the OPERATOR_DEF_BUILTIN inherit from BUILTIN_OPERATORS? I believe the BUILTIN_OPERATORS should be an enumeration (like [OPERATOR_KIND in AOM1.4](https://specifications.openehr.org/releases/AM/Release-2.0.6/AOM1.4.html#_operator_kind_enumeration)). Then the OPERATOR_DEF.identifier would be of type BUILTIN_OPERATORS/OPERATOR_KIND (like it is in AOM1.4 [EXPR_OPERATOR.operator](https://specifications.openehr.org/releases/AM/Release-2.0.6/AOM1.4.html#_expr_operator_class). The JSON would be cleaner: ```json "operator_def": { "_type": "OPERATOR_DEF_BUILTIN", "identifier": "matches" }, ``` --- ## Post #21 by @thomas.beale [quote="borut.jures, post:20, topic:2203"] Should the OPERATOR_DEF_BUILTIN inherit from BUILTIN_OPERATORS? [/quote] `op_table` is static, so it acts like a singleton object. The owning class just populates the table at startup time. You could also use the GoF Singleton pattern to achieve the same effect (which doesn't use inheritance). In most languages these days you don't need to inherit, you can just reference `BUILTIN_OPERATORS.op_table`(or in Java - `BuiltinOperators.opTable()`.# It's not an enumeration though, it's a table of the form: ``` |"plus" | "+ " |"multiply" | "*", "." etc ``` Any logical operator might have a number of alternative symbols. --- ## Post #22 by @borut.jures I sometimes forget how inexperienced I must sound with such questions :flushed: We both know that BUILTIN_OPERATORS is a singleton just by looking at the model. However I'm asking for a friend - my generator :wink: The generator knows only what is in the computable specifications - the BMM files. I posted the question because there is no information that BUILTIN_OPERATORS is a singleton or that op_table is static in the BMM. BUILTIN_OPERATORS is the second ancestor of the OPERATOR_DEF_BUILTIN. OPERATOR_DEF_BUILTIN "extends" OPEREATOR_DEF and "implements" BUILTIN_OPERATORS. Since the BUILTIN_OPERATORS.op_table is not marked as static it needs to be "implemented" in OPERATOR_DEF_BUILTIN. The only way I know how to "implement" a property from an ancestor is by adding it to the OPERATOR_DEF_BUILTIN class (I tried with mixins but that didn't work out). BUILTIN_OPERATORS.op_table is marked as mandatory in BMM which means it must be present for every OPERATOR_DEF_BUILTIN instance. A solution would be to add "is_im_singleton" and/or "is_im_static" to the BMM classes/attributes. Then BMMs would have the same information as we. I'm not sure if that is a realistic expectation? So I have two options with the current BMM: - remove BUILTIN_OPERATORS as the second ancestor of OPERATOR_DEF_BUILTIN - remove "is_mandatory" for BUILTIN_OPERATORS.op_table so that the "fromJson()" doesn't report an error if it is missing in OPT2 JSON. --- I'm aware of only one other class that has to "implement" properties found in its ancestors. It is where AUTHORED_ARCHETYPE "extends" ARCHETYPE and "implements" AUTHORED_RESOURCE which has mandatory properties. The generator can handle this scenario even for reading the OPERATIONAL_TEMPLATE from JSON. Edit: The problem is setting mandatory properties at the instantiation of OPERATIONAL_TEMPLATE instance: - OPERATIONAL_TEMPLATE constructor can call its ancestor's constructor in AUTHORED_ARCHETYPE. - AUTHORED_ARCHETYPE constructor can call its ancestor's constructor in ARCHETYPE. - AUTHORED_ARCHETYPE constructor cannot call its second ancestor's constructor in AUTHORED_RESOURCE. - Thus AUTHORED_RESOURCE's mandatory properties cannot be set when creating an instance of OPERATIONAL_TEMPLATE. --- ## Post #23 by @pieterbos [quote="sebastian.iancu, post:14, topic:2203"] Is this not rather `_type` ? [/quote] Yes, it should be. In Archie this is configurable because of when I built it, it was not yet standardised as `_type`, I must have used the wrong configuration in the vs code extension. Will create an issue and fix later --- ## Post #24 by @pieterbos [quote="borut.jures, post:19, topic:2203"] “openehr_expression_104.bmm” has [EXPR_BINARY_OPERATOR](https://specifications.openehr.org/releases/AM/latest/AOM1.4.html#_expr_binary_operator_class). I used this type for the ASSERTION.expression [/quote] Is this just for the archetype slots? Then it can be simplified and all archetypes I have seen will just parse. If it is for the rules section, then you need more than just a binary operator. By the way, it looks like I can make Archie and the VSCode plugin easily output JSON as in the model in that diagram generated from the BMM for archetypes and OPT 2s, configurable to switch to the new version. Just the operator def might be different, as that is an enum in archie. Even the new model looks mostly possible, but will be more work to do. i will try soon if it's possible. It will still all just parse to the same model in Archie that I will not change right now. --- ## Post #25 by @borut.jures [quote="pieterbos, post:24, topic:2203"] Is this just for the archetype slots? [/quote] Yes. --- Since my OPERATIONAL_TEMPLATE fromJson() method is generated from AM BMM the OPT2 JSON must be in exactly the structure of the AM specifications. I didn't know if you will have time to add the required changes to Archie so I wrote OPT2 to JSON converter. --- ## Post #26 by @pieterbos There appear to be more differences, unfortunately. Differences between the model in Archie and https://specifications.openehr.org/releases/BASE/Release-1.0.4/expression.html#_assignment_class that are not simple renames that I found so far: - EXPR_FUNCTION.function_def is of type FUNCTION_DEF. It is EXPR_FUNCTION.function_name as a string in Archie. There is no function_def class in Archie. - OPERATOR_DEF_BUILTIN is an enum in Archie (renames are easy, parsing/serialization slightly more tricky) - EXPR_TYPE_DEF is the enum EXPRESSION_TYPE in archie (renames are easy, parsing/serialization slightly more tricky) - there is no ASSINGMENT in Archie, just variable declaration, not even in the grammar. - the for all statement is missing in the specification. It cannot be expressed as a simple binary operator, and in archie is a separate class inheriting from operator with variable_name, left_operator (the expression pointing to a collection of values) and right_operand (the expression to be evaluated as an assertion for every member of the collection) - **precedence_overridden** is in binary operator in the spec, in expression in Archie. Minor, in archie it's possible to store more places where `()` can appear in the grammar, but they are pretty much meaningless in execution if not around an instance of OPERATOR I might find more later. --- ## Post #27 by @thomas.beale [quote="borut.jures, post:22, topic:2203"] The generator knows only what is in the computable specifications - the BMM files. I posted the question because there is no information that BUILTIN_OPERATORS is a singleton or that op_table is static in the BMM. [/quote] Right, now I get where you are coming from. Sorry for the basic info (but quite often we have newbies visiting these posts as well, so us experienced folk should not hold back on simple explanations). All the issues you point to in the BMM are addressed in the new form, i.e. the one that is not yet quite ready. I'll have to have a think about what we can do in the short term... Skimming your ideas - they sound ok to me - definitely you can remove the inheritance for the operator table, that's not a modern way to access a singleton object. I'll have to ponder the rest though for a bit longer. --- ## Post #28 by @pieterbos My conclusion is that this is a bit of a mess. Archie has an exact implementation as the model was specified when I implemented it. The only deviations in the serialisation are the missing EXPR_ prefixes to the type names, and missing op_ prefixes for the operator enum, and the addition of a modulo operator that was missing from the class definition. This matches exactly with the serialisation in the AOM 1.4 specification, at least for the archetype slots. For at least the archetype slots, I can add a configurable rename so it will output the literals as EXPR_LITERAL (they were called LEAF before!) or the old version. The operator_def is tricky. If I have to make a sort of possibility of a migration path, I can output and accept both operator (enum, so a string), and operator_def (object with identifier). The operator_def seems very strange to me in a serialisation format. I think the op_table does not belong in the json as it has no meaning there, and certainly cannot be changed from outside a system. Then if we decide to switch to the BMM_ASSERTION, everything will change again, the operator def will change to a rather complicated function_def. That will be a much harder migration path, probably with some way to accept and generate both versions of the formats. note that this is not just for the rules section, also the archetype slots, although that is just a subset of the entire language. --- ## Post #29 by @pieterbos First attempts gives the following json for an expression in an archetype slot. This is a bit different than @borut.jures s example - this one has the following differences, which I consider to follow the spec: - `EXPR_ARCHETYPE_REF` for the path reference - right operand is a `EXPR_CONSTRAINT` instead of a literal. And where it still deviates from the standard, but I think the standard needs a correction: - `EXPR_ARCHETYPE_REF` has no 'item' field, since it does not make sense to add it (why and what should it be filled with?) - no op_table, since it makes no sense to include at all. - both operator, operator_def and symbol for reasons stated above - some convenience fields such as path added, that are very useful in javascript. I could easily add an option to get rid of them, as I have done in the RM. ``` "expression" : { "_type" : "EXPR_BINARY_OPERATOR", "type" : "BOOLEAN", "precedence_overridden" : false, "operator" : "op_matches", "symbol" : "matches", "left_operand" : { "_type" : "EXPR_ARCHETYPE_REF", "precedence_overridden" : false, "path" : "archetype_id/value" }, "operator_def" : { "identifier" : "matches" }, "right_operand" : { "_type" : "EXPR_CONSTRAINT", "precedence_overridden" : false, "item" : { "_type" : "C_STRING", "rm_type_name" : "string", "node_id" : "id9999", "constraint" : [ "/openEHR-EHR-INSTRUCTION\\.medication\\.v1/" ], "attributes" : [ ], "logical_path" : "/", "allowed" : true, "required" : false, "prohibited" : false, "path" : "/" } ``` --- ## Post #30 by @thomas.beale [quote="pieterbos, post:28, topic:2203"] My conclusion is that this is a bit of a mess. Archie has an exact implementation as the model was specified when I implemented it [/quote] If that is true, it must be that I am working off the wrong version (there is no obvious version to work off, because there was no release). But since I have created the BASE 1.0.4 branch to capture the intended version, we'll keep mutating that until it matches the implementations. [quote="pieterbos, post:28, topic:2203"] For at least the archetype slots, I can add a configurable rename so it will output the literals as EXPR_LITERAL (they were called LEAF before!) [/quote] Hm I must admit I don't even remember that, must have been a very old version - I have had a habit of using the 'expr_' prefix for over 20y! [quote="pieterbos, post:28, topic:2203"] If I have to make a sort of possibility of a migration path, I can output and accept both operator (enum, so a string) [/quote] I think we should mutate the branch version of the spec, not your implementation. Let's not create more work. [quote="pieterbos, post:28, topic:2203"] The operator_def seems very strange to me in a serialisation format. I think the op_table does not belong in the json as it has no meaning there, and certainly cannot be changed from outside a system. [/quote] Correct, that is like including a constant in a data serialisation - not useful and not part of the data. [quote="pieterbos, post:28, topic:2203"] Then if we decide to switch to the BMM_ASSERTION, everything will change again, the operator def will change to a rather complicated function_def [/quote] We won't do that in this branch version. The new Expression Language will do that, but that's a completely different thing. I'll start having a look at some of the things you have listed. But remember - whatever version you originally worked off, it was incomplete, and contained errors, so what we specify now will necessarily be some upgrade on that original. --- ## Post #31 by @pieterbos [quote="thomas.beale, post:30, topic:2203"] Hm I must admit I don’t even remember that, must have been a very old version - I have had a habit of using the ‘expr_’ prefix for over 20y [/quote] Sorry, the expr_ prefix was in the zpecification, that omission was my mistake - I mean the original literal was called EXPR_LEAF. This means I have to do some renames anyway, which is annoying but fine. I have time to respond to the rest tomorrow. --- ## Post #32 by @borut.jures [quote="pieterbos, post:29, topic:2203"] * `EXPR_ARCHETYPE_REF` for the path reference * right operand is a `EXPR_CONSTRAINT` instead of a literal. [/quote] I wanted to use these two in my JSON this morning and found out they are missing in the BMM files (that is probably why I used EXPR_LITERAL - I have to learn to always check the web specifications and compare them with the BMMs). They are in the specifications for [AOM 2.0.6](https://specifications.openehr.org/releases/AM/Release-2.0.6/AOM2.html#_class_descriptions_2) and [AOM 2.2.0](https://specifications.openehr.org/releases/AM/Release-2.2.0/AOM2.html#_class_descriptions_2). @thomas.beale Can they be added please? Pieter also made a comment about the EXPR_ARCHETYPE_REF.item field: [quote="pieterbos, post:29, topic:2203"] `EXPR_ARCHETYPE_REF` has no ‘item’ field, since it does not make sense to add it (why and what should it be filled with?) [/quote] --- BUILTIN_OPERATORS in OPERATOR_DEF_BUILTIN: [quote="thomas.beale, post:27, topic:2203"] definitely you can remove the inheritance for the operator table, that’s not a modern way to access a singleton object. [/quote] [quote="thomas.beale, post:30, topic:2203"] Correct, that is like including a constant in a data serialisation - not useful and not part of the data. [/quote] @thomas.beale Can the BUILTIN_OPERATORS as the second ancestor of OPERATOR_DEF_BUILTIN be removed from the BMMs? --- ## Post #33 by @pieterbos [quote="thomas.beale, post:30, topic:2203"] Hm I must admit I don’t even remember that, must have been a very old version - I have had a habit of using the ‘expr_’ prefix for over 20y! [/quote] The expr_ prefix was definitely there, I for some reason did not implement it. Looks like I implemented https://github.com/openEHR/specifications-AM/blob/5addcf864d9ab0f1439cf86ac12311c4fbf7b72b/docs/AOM2/AOM2.html . Modification I made that I do not know the reason for: - instead of a LIST, I added a RULES_SECTION class, with LIST and a string content. Not sure why. Modifications I had to make to make this work: - added a FOR_ALL_STATEMENT class, because it does not fit in BINARY_OPERATOR (missing the variable declaration), see https://github.com/openEHR/archie/blob/master/aom/src/main/java/com/nedap/archie/rules/ForAllStatement.java - ASSERTION does not have a variables attribute. Does not make sense to have, and the class wasn't defined in the spec back then. - EXPR_ARCHETYPE_ID_CONSTRAINT is implemented, but never used, since at grammar level, this cannot be easily instantiated - a normal Constraint with a C_STRING is used in these places. - MODEL_REF has a variableReferencePrefix attribute in Archie, to indicate the path starts with a variable (as used in for_all) - OPERATOR_KIND has op_module added - added FUNCTION to implement the function calls specified in the language spec, which was missing in the object model, with attributes: ``` String functionName; List arguments; ``` So, what I can relatively easily change: - renaming of classes, probably even parsing both and generating only the new ones, configurable to not break older clients - adding new attributes, like operator_def, next to the existing one - making the ARCHETYPE.rules attribute return a LIST again, configurable to support older clients. - changing inheritance of FOR_ALL_STATEMENT to binary operator instead of operator. And one for readability: - OPERATOR_KIND is an enum, but not an integer - it uses the string name, so op_eq, etc. Well actually in archie for some reason, just 'eq', but that can be changed. So, what should we change, and in archie or the specification? --- ## Post #34 by @thomas.beale I'll need a few days to get onto this, but let's change that BASE 1.0.4 spec as much as coherently possible - if it is to be useful, it might as well be reverse-engineered from your Nedap implem - which we know works. If we get stuck (probably we will on some detail), we'll work out a solution. I am not in favour of you having to do more work in your implem - the reason for this branch EL spec is to provide a spec that your implem is based on. So let's get as far as we can before you start making any Archie changes. --- ## Post #35 by @pieterbos Pull request to do the rules changes in https://github.com/openEHR/archie/pull/377 . Mostly configurable to be able to upgrade archie without too much trouble, and parsing is backwards compatible for easier upgrading. Most work there is the configuration and the mechanism, not the renaming. I made it a draft pull request. So, @thomas.beale , are the names in https://github.com/openEHR/archie/pull/377/files#diff-1632ab74a28cca19f1a29a15e9b0afb5d4a87ee8c722ec0b776a2572929d6684R40-R61 as they should be? I will add tests of course. After this is done, next week we hope to merge all this and be able to release a major archie release soon. Since it's not fully compatible with Archie 1, will likely be 2.0.0 (semver). --- ## Post #36 by @thomas.beale The changes look right to me - I wonder if you are making things too configurable however? The Archie code will break for sure but I suspect your (i.e. Nedap) system is the only user of that code so far - EhrBase doesn't have any rule logic in its templates as far as I am aware - so dealing with the breakages locally is pretty trivial. You could arguably consider this change a patch-level change to Archie if we agreed consider the missing name prefixes an 'error' - not casting aspersions within this group, I'm just thinking about how it looks from the outside / under semver logic. --- ## Post #37 by @pieterbos There are more changes that break things, also to the API of Archie, so it's a major release. No, not too configurable. We have android apps parsing these rules with Archie, and we need to be able to update both our server and our apps without waiting for all apps to be updated. This means we need a proper migration path where this configurability is absolutely necessary. --- ## Post #38 by @thomas.beale [quote="pieterbos, post:37, topic:2203"] we need to be able to update both our server and our apps without waiting for all apps to be updated [/quote] Good point - what is in the JSON matters, and if you don't want to be chained to doing some sort of magic whole-of-system instant update, then you have to allow both. I do wonder though if the config settings can be dispensed with in a later ?minor version - to reduce complexity a bit, and also not to give new Archie users the idea that there really is an intentional choice available here? --- ## Post #39 by @pieterbos Yes, some of these config settings (not all!) can be removed in a later version. I could mark the configuration settings as deprecated right from the start. But actually removing them will be a major version no matter what, even if they are deprecated, since it changes the behaviour considerably and will break apps if it is still used. --- ## Post #40 by @borut.jures Great update Pieter! --- [quote="pieterbos, post:35, topic:2203"] @thomas.beale , are the names in [Fix json rules by pieterbos · Pull Request #377 · openEHR/archie · GitHub](https://github.com/openEHR/archie/pull/377/files#diff-1632ab74a28cca19f1a29a15e9b0afb5d4a87ee8c722ec0b776a2572929d6684R40-R61) as they should be? [/quote] @thomas.beale - EXPR_CONSTANT - EXPR_CONSTRAINT - EXPR_ARCHETYPE_ID_CONSTRAINT - EXPR_ARCHETYPE_REF are missing in "openEHR_am_206.bmm" (and 210, 220, 230). [AOM 2.0.6](https://specifications.openehr.org/releases/AM/Release-2.0.6/AOM2.html#_class_descriptions_2) --- ## Post #41 by @DavidIngram 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 --- ## Post #42 by @pieterbos 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. --- ## Post #43 by @thomas.beale [quote="pieterbos, post:42, topic:2203"] Archie used RULE_SECTION [/quote] Is RULE_SECTION something like RULE_GROUP, conceptually in your implem? --- ## Post #44 by @pieterbos [quote="thomas.beale, post:43, topic:2203"] Is RULE_SECTION something like RULE_GROUP, conceptually in your implem? [/quote] No, just a representation of the entire rules section of the archetype. I have no idea why I introduced that part. --- ## Post #45 by @borut.jures 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: ![Screenshot 2022-01-08 at 08.24.35|651x500](upload://l4Al15YEQKrGfy5JovsuyoDKqBm.png) ...and here is a COMPOSITION class (Vital signs OPT): ![Screenshot 2022-01-08 at 08.22.40|493x500](upload://iMFwdaQKgap4P9BphfXux2dgED8.png) 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 :blush:): ![Screenshot 2022-01-08 at 08.48.19|690x286, 50%](upload://9EV70H4M4PXUicqaKnK1nosQ1Dt.png) ...and for height in cm or inches: ![Screenshot 2022-01-08 at 08.43.16|690x218](upload://aJoF26U96chVN6P8t0h3oyDglat.png) ...and for blood pressure (no tuples): ![Screenshot 2022-01-08 at 08.33.52|348x500](upload://nc7yEtGi4ljEZndNXCoK2s57XzK.png) --- ## Post #46 by @thomas.beale [quote="pieterbos, post:33, topic:2203"] Modifications I had to make to make this work: * added a FOR_ALL_STATEMENT class, because it does not fit in BINARY_OPERATOR (missing the variable declaration), see [archie/ForAllStatement.java at master · openEHR/archie · GitHub ](https://github.com/openEHR/archie/blob/master/aom/src/main/java/com/nedap/archie/rules/ForAllStatement.java) * ASSERTION does not have a variables attribute. Does not make sense to have, and the class wasn’t defined in the spec back then. * EXPR_ARCHETYPE_ID_CONSTRAINT is implemented, but never used, since at grammar level, this cannot be easily instantiated - a normal Constraint with a C_STRING is used in these places. * MODEL_REF has a variableReferencePrefix attribute in Archie, to indicate the path starts with a variable (as used in for_all) * OPERATOR_KIND has op_module added * added FUNCTION to implement the function calls specified in the language spec, which was missing in the object model, with attributes: [/quote] 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. --- ## Post #47 by @thomas.beale [quote="pieterbos, post:33, topic:2203"] Modifications I had to make to make this work: * added a FOR_ALL_STATEMENT class, because it does not fit in BINARY_OPERATOR (missing the variable declaration), see [archie/ForAllStatement.java at master · openEHR/archie · GitHub ](https://github.com/openEHR/archie/blob/master/aom/src/main/java/com/nedap/archie/rules/ForAllStatement.java) [/quote] 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. --- ## Post #48 by @thomas.beale 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. --- ## Post #49 by @pieterbos Archie with the mentioned JSON changes in this thread was released last week. --- ## Post #50 by @thomas.beale [quote="pieterbos, post:33, topic:2203"] Modifications I had to make to make this work: * ASSERTION does not have a variables attribute. Does not make sense to have, and the class wasn’t defined in the spec back then. [/quote] I think this must be some intermediate form of model - I couldn't find this in the [currently published version](https://specifications.openehr.org/releases/BASE/Release-1.0.4/expression.html#_assertion_class), and it is not in the UML. --- ## Post #51 by @thomas.beale [quote="pieterbos, post:33, topic:2203"] Modifications I had to make to make this work: * EXPR_ARCHETYPE_ID_CONSTRAINT is implemented, but never used, since at grammar level, this cannot be easily instantiated - a normal Constraint with a C_STRING is used in these places. [/quote] 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. --- ## Post #52 by @thomas.beale [quote="pieterbos, post:33, topic:2203"] Modifications I had to make to make this work: * OPERATOR_KIND has op_module added [/quote] 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...) --- ## Post #53 by @thomas.beale [quote="pieterbos, post:33, topic:2203"] added a FOR_ALL_STATEMENT class, because it does not fit in BINARY_OPERATOR (missing the variable declaration), see [archie/ForAllStatement.java at master · openEHR/archie · GitHub ](https://github.com/openEHR/archie/blob/master/aom/src/main/java/com/nedap/archie/rules/ForAllStatement.java) [/quote] 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](https://specifications.openehr.org/releases/BASE/Release-1.0.4/expression.html#_core_package). --- ## Post #54 by @sebastian.iancu 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 https://specifications.openehr.org/releases/AM/Release-2.0.6/AOM2.html#_serialisation_model) but in the `latest` is not (see same `P_ARCHETYPE_SLOT'` on diagram at https://specifications.openehr.org/releases/AM/latest/AOM2.html#_serialisation_model). 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: * [ASSERTION Class in AM 2.0.6/AOM1.4 ](https://specifications.openehr.org/releases/AM/Release-2.0.6/AOM1.4.html#_assertion_class) * [ASSERTION class in BASE 1.0.4 ](https://specifications.openehr.org/releases/BASE/Release-1.0.4/expression.html#_assertion_class) * [BMM_ASSERTION in LANG latest ](https://specifications.openehr.org/releases/LANG/latest/bmm.html#_bmm_assertion_class) --- **Canonical:** https://discourse.openehr.org/t/assertion-in-openehr-expression-104-bmm-is-not-in-accordance-with-the-specifications/2203 **Original content:** https://discourse.openehr.org/t/assertion-in-openehr-expression-104-bmm-is-not-in-accordance-with-the-specifications/2203