Globally unique class names

EXPR_TYPE_DEF is specified in two files:

  • components/LANG/Release-1.0.0/openehr_lang_100.bmm

  • components/BASE/Release-1.0.4/openehr_expression_104.bmm.

All the other types in “lang_100” have the name “TYPE_abc”. Only “EXPR_TYPE_DEF” has the “EXPR_” prefix.

All the types in “expression_104” have the prefix “EXPR_”.

expression_104:
"EXPRESSION",
"EXPR_VALUE",
"EXPR_VARIABLE_REF",
"EXPR_LEAF",
"EXPR_OPERATOR",
"EXPR_LITERAL",
"EXPR_UNARY_OPERATOR",
"EXPR_BINARY_OPERATOR",
"EXPR_VALUE_REF",
"EXPR_FUNCTION",
"EXPR_TYPE_DEF"

lang_100:
"EXPR_TYPE_DEF",   <== the odd one
"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"

Name “TYPE_DEF” is not used anywhere else. Shouldn’t “EXPR_TYPE_DEF” in the “lang_100” use “TYPE_DEF” to follow the same pattern as the rest of the classes?

“expression_104” is included in components/AM/openEHR_am_230.bmm which is also odd since the “am_230” also includes “base_110”. I would expect there would also be “expression_110” (even if it is the same as expression_104).


I found out this when an UML diagram for EXPR_LEAF included “EXPR_TYPE_DEF” from “lang_100” instead of “expression_104”.

As @thomas.beale mentioned before, using full package names for classes solves this. However I try to keep URLs for the diagrams as short as possible (also specifying classes to include on the custom diagrams can be done only using a name).

Using unique class names (if possible) would also simplify mentioning them in an unambiguous way.

So far I found only 2 non-unique class names:

  • EXPR_TYPE_DEF in “lang_100” and “expression_104”
  • EVENT in “proc_160” and “rm_structures_nnn”

I guess it isn’t possible to change the naming at this point (?) and I’ll have to use longer URLs for the diagrams?

First option is to add model_name to the URLs. But “TASK_PLANNING” is much longer than “PROC”.

The second option is to add “PROC”, “LANG”,… to the urls.

What are the community’s preferences for the URL naming?

1 Like

I started adding full namespace support to the validator and realised that even BMM is not using namespaces.

Example: components/PROC/Release-1.6.0/openehr_proc_task_planning_latest.bmm

["PARAMETER_DEF"] = <
    name = <"PARAMETER_DEF">
    properties = <
        ["name"] = (P_BMM_SINGLE_PROPERTY) <
            name = <"name">
            type = <"String">
            is_mandatory = <True>
        >
        ["type"] = (P_BMM_SINGLE_PROPERTY) <
            name = <"type">
            type = <"EXPR_TYPE_DEF">  <== which EXPR_TYPE_DEF is this (LANG or BASE)?
            is_mandatory = <True>
        >

Since property types don’t specify package names, we don’t know which type/class is meant. In the above example either EXPR_TYPE_DEF from “lang_100” or from “expression_104” could be used.

This wasn’t an issue before “lang_100” and “proc_100” since before that all the classes were globally unique.

I’m I missing something and non-unique class names can be used for properties without also specifying their package?

I think there is a need for a package dependency maps: some specs release requires others to be used, or are not compatible with others.
I this case (@thomas.beale better correct me), the EL was part of BASE 1.0.4, but later was extracted as a separate component EL 1.0.0 (which supposed to be used with BASE 1.1+). There are similar issues on AM 1.4 and AOM Profile vs BASE, or BASE vs RM 1.0.2. this dependencies are nowhere expressed in a computational form (as far as I know).

The EXPR_TYPE_DEF classes were experimental and are discontinued, so you could rename this however you want; for EVENT, I suggest for now you rename it in your private clone as ‘PLAN_EVENT’, which we’ll probably do one day anyway. No need to complicate things in your local setup for now.

1 Like

OK. I’ll rename it locally for now.

I’ll rename EVENT to BASE_EVENT, since PLAN_EVENT already exists in PROC.


I guess this means that I can stop adding support for namespaces when validating BMMs :thinking:

1 Like

Having unique class names would be great for keeping the upcoming URN syntax short/compact too.

3 Likes

I see two options at the moment:

  1. Use package name + type name when specifying property type in BMMs. That would be unreadable due to the length.
  2. Keep using class names as globally unique. This doesn’t mean we shouldn’t use namespaces for working classes (I use short URL but in the backend I use package names + class name).

Most class names are unique without trying. Only the EVENT in PROC is non-unique and it can get some prefix to make it unique.

To me the most important part of having unique names is that everybody knows about which class we are talking about (without mentioning its model/package).

That is our general approach as well; I’m not sure why we didn’t call PROC:EVENT something unique. But this can be changed, so we can solve it.

2 Likes

IMHO with package+class being unique is enough, though having all classes from all models banned uniquely would be a quality sign.

1 Like