Inconsistency in demographic specs: ACTOR.roles and ACTOR.languages HTML vs. PDF versions

Raise

Analysis

Raise

Analysis

Description

In https://specifications.openehr.org/releases/1.0.2/architecture/rm/demographic_im.pdf ACTOR.roles is 0..1 ACTOR.languages is 0..1 In Demographic Information Model (same spec and version, just the HTML version ACTOR.roles is 1..* ACTOR.languages is 1..* I believe the PDF version is using the existence cardinality and the HTML version is using the cardinality of the list. Though if the attribute can be optional (existence 0..1), then de cardinality can’t be 1..*, unless the interpretation is: the attribute is optional, though if it’s present, then it should contain at least one element. Note the languages type in the PDF is declared as List<DV_TEXT> [0..1], and in the HTML it’s DV_TEXT [1..*], so the List is omitted (implicit type). Same happens with ACTOR.roles. Also PARTY.reverse_relationships in the PDF is Set<LOCATABLE_REF> [0..1] while in the HTML it’s LOCATABLE_REF [0..*]. In the HTML specs for demographics on 1.0.3, 1.0.4 and 1.1.0, it follows how types are defined in the 1.0.2 spec in HTML. I found those differences confusing. The problem is the JSON schemas I’m working on, depend on the correct interpretation of the spec’s existence and cardinality.

Activity

Show:

Pablo Pazos October 13, 2022 at 1:15 AM

I have found in the demographic 1.0.2 HTML version, in the tables the attributes are 1..1 languages: List<DV_TEXT> and 1..1 roles: List<PARTY_REF> https://specifications.openehr.org/releases/RM/Release-1.0.2/demographic.html#_actor_classwhen in the UML diagram those are languages: DV_TEXT [1..*] and roles: PARTY_REF [1..*].

In 1.0.3, 1.0.4 and 1.1.0 the table also has List<xxx>, in 1.0.4 the table changes from 1..1 to 0..1. Shouldn’t the tables have the same info, including the multiplicity as in the UML diagram?

Pablo Pazos October 12, 2022 at 5:45 PM

Thanks @Thomas Beale the more I review the specs with the goal of defining items for the conformance verification framework, the more I find we don’t have a proper deprecation process, we just keep specs alive and when we try to do something with them someone says “that is not longer in use” We need to formally say “this spec is deprecated”, “this spec is obsolete” (deprecation comes before obsolescence), “this spec is archived” (for historical purposes), etc.

I’m for sure using the PDF specs for 1.0.2 since those where the only specs available for 1.0.2 and the HTML version for 1.0.2 came years later when 1.0.3 was released.

Besides that, there are other issues with the demographic models,

In 1.0.3 ACTOR.languages and ACTOR.roles were 1..* which is too restrictive. This was changed to 0..* in 1.0.4. Then again, 1.0.3 is not deprecated nor obsolete nor archived. Then, when checking conformance against that spec is needed. But since XML/JSON schemas comply with the RM, in the schemas languages and roles need an object there for all ACTOR instances, even though it is not needed in the JSON or XML, so dummy data is needed to be compliant with those versions.

The other one I mentioned in discourse: PARTY..identities is 1..* in all versions, even 1.1.0, which is also too restrictive, specially for ROLE instances which might not require an identity, but will need a dummy one just to comply with the spec multiplicity.

I would like to discuss the deprecation process in a SEC meeting so we can start defining that and get the specs properly tagged in the specifications page.

Thomas Beale October 12, 2022 at 10:06 AM

The PDF specs didn’t have formal UML, and did not represent certain things correctly, including the things you mention. The HTML specs are correct. The UML way to represent attr: List<X> is attr: X [*] (or attr: X [1..*]) and optionally with a constraint like {unique} if you want to indicate a set, rather than a list. We convert those kind of things in the UML extractor into the proper form that people expect, i.e. attr: List<X>.

Please avoid the PDF specs, they are no longer in use