Add rm_visibility top-level section to state hide/show and RM attribute aliasing.

I need to invest some time sometime (sic) to improve my understanding of ADL to such a degree to be able to understand such changes. However, just as a proof-of-work I hereby declare the following two typos I found:

• archetype modellers sometimes need to be know,

• annotations are mainly relate to nodes.

I think the rm_overlay feature is fine as it is defined in your proposal of changes to the specification. I can see why renaming could be done with paths instead. I do not have a clear preference of one over the other.

So I’m fine with accepting the current change, as it solves a real issue. But maybe anyone else has a different idea?

Reviewing this again today, and the changes I actually did to the spec, I think it achieves what is needed without further changes. If we want to make this edge case of paths based on specific sub-types more explicit, I think we should indicate that paths could be something like items[id1]/value[_type = 'DV_CODED_TEXT']/defining_code` .

However, there is another approach that has become clearer with my work on Decision Logic Modules, which is to treat the ‘code’ for an attribute as just the name of the attribute - you still need its path, because attribute names are far from unique (e.g. ‘items’). This approach would be a bit different from the way I did it, i.e. entails using Terminology definitions for path-qualified attributes like:

I actually think this is a better approach because it separates the attribute ‘renaming’ completely from the hide/show feature. The documentation for this would be: for any attribute for which you want an alternative name (including for translations), add an entry to term_definitions with the attribute path, and standard definition for text, description etc.

Suggest @Ian McNicoll , @Pieter Bos , @Diego Bosca , @Borut Fabjan all have a look at the above suggestion.

I think we’ve all learned something here today

Does that mean you have some ‘DV_CODED_TEXTat’ code in the terminology section of the archetype?

Nope, RM archetype terminology section is empty.

'DV_CODED_TEXTat' is a pretty weird label…!

It is, I don’t exactly remember the rationale for that specific thing we decided ~15 years ago, but probably because it’s easy to test if a nodeid starts with ‘at’ (archetype node) or ends with ‘at' (rm archetype node). I think we didn’t put the type exactly in there because some RMs allow some very nasty things as types (or attributes), so always transforming and making it explicit helps to treat those cases too (this doesn’t affect openEHR AFAIK, but could potentially affect any other standard where AOM is used)

In any case, this kind of paths was what we came with when dealing with unique RM paths that are not present in the archetype. Not saying that we must use the kind of ids we use, but that this mechanism solves the problem of identifying RM paths.