Update BMMs to latest version + json schema improvements

[pieterbos]

• updates BMM to the latest versions. Related PR for fixes to the official BMMs: Fixes after running the Archie validator on the current BMM models specifications-ITS-BMM#17
• made ACTIVITY.action_archetype_id mandatory (as it is in spec)
• ignored DV_QUANTITY.property in json schema output
• added entry points

goal is to fix the changes addressed in openEHR/specifications-ITS-JSON#14, as discussed in https://discourse.openehr.org/t/multi-rm-json-schema-validation-and-current-schema-issues/3002/21

resulting JSON schema can be found in openEHR/specifications-ITS-JSON#15

Note that this is work in progress and this PR is to make this easy to find and to review the changes to the BMM and json schema generator.

TODO list:

• Load most recent BMMs from https://github.com/openehr/specifications-its-BMM
• Remove DV_QUANTITY.property
• Fix hash to json schema mapper
• fix entry point list to list below
• value of all ISO_8601 types is now required
• terminology_code.uri is no longer required
• GENERIC_CONTENT_ITEM.other_details should be Hash<String, String>
• check all the things that are now a hash if they actually should be
• RESOURCE_DESCRIPTION_ITEM.other_details is optional in the RM but required in the schemas.
• FOLDER.details is in the 1.0.4 Schema but was added in the RM 1.1.0, so should be removed from the 1.0.4 Schema.
• ACTIVITY.action_archetype_id is mandatory in the RM but in schemas 1.0.3 and 1.0.4 is not required.
• REMOVE IS_8601_TYPE from the schemas
• check value attribute of DV_URI/DV_EHR_URI to be required
• Replace URI from the schema with a uri-reference formatted string (used in TERMINOLOGY_CODe
• get rid of some unused RM classes
  • ARCHETYPE_HRID
  • should this include the resource part, so RESOURCE_DESCRIPTION_ITEM, etc, or should they be separate in task planning?
• check if we can use the iso8601 types in json schema. Cannot, no partial date/time
• check changes on RESOURCE_DESCRIPTION
• check why MULTICPLICITY_INTERVAL and CARDINALITY have been added
• fix failing test
• find possible earlier discussion on activity.action_archetype_id: https://openehr.atlassian.net/browse/SPECRM-104
• check that EXTRACT_ENTITY_MANIFEST.other_ids is a list of strings, rather than a hash - discussion, the text says 'Other identifiers that may be used to find the entity at the target system, keyed by type'. if it has keys, it IS a hash, but the specification says list. Which one is correct?
• Removed RESOURCE_DESCRIPTION.parent_resource from json, it's a runtime attribute, not serializable
• Removed Cardinality and Multiplicity interval from the RM json - this is AOM only
• Checked that ACTOR.roles and language are indeed correctly marked mandatory in RM 1.0.3 (see specification!)

To be decided

• Should uri-reference be used in more places? If so, could be changed in BMM
• decide if we can and should add the terminology codes as enum constraints to the json schema (might be a separate issue from this one!)
• Decide on whether some OBJECT_REFs should no longer allow some OBJECT_REF subclasses in json schema
• Decide on whether VERSIONED_OBJECT should only allow a short list of types, instead of just 'object', and if so, which types.
• Decide whether to make archetype_details mandatory for classes that must be an archetype root (observation, composition, person, etc.)

New entry point list:

COMPOSITION
OBSERVATION
EVALUATION
ACTIVITY
ACTION
SECTION
INSTRUCTION
INSTRUCTION_DETAILS
ADMIN_ENTRY
CLUSTER
CAPABILITY
PERSON
ROLE
ORGANISATION
AGENT
GROUP
PARTY_IDENTITY
ITEM_TREE
CONTRIBUTION
EHR
EHR_STATUS
ORIGINAL_VERSION
IMPORTED_VERSION
HISTORY
ITEM_TABLE
ITEM_LIST
ITEM_TREE
ITEM_SINGLE
ITEM_TABLE
ELEMENT

[J3173]

Do bmm/openEHR/components/BASE/Release-1.0.4/openehr_base_104.bmm, bmm/openEHR/components/BASE/Release-1.0.4/openehr_expression_104.bmm and/or the AM BMM files also need to be added here?

[pieterbos]

It's possible. That is however a bigger change, and the AOM files are never needed for most archie users, who just want to validate archetypes against the BMM. And adding them would cost extra startup time. So, that could be a separate PR, with a lazy loading approach in case you need the AOM BMMs?

[J3173]

Also tested this with our existing code and everything seems to work.

[codecov]

Codecov Report

Base: 71.42% // Head: 71.42% // Increases project coverage by +0.00% 🎉

Coverage data is based on head (24ee113) compared to base (a55864a).
Patch coverage: 87.01% of modified lines in pull request are covered.

Additional details and impacted files

@@            Coverage Diff            @@
##             master     #459   +/-   ##
=========================================
  Coverage     71.42%   71.42%           
- Complexity     6758     6765    +7     
=========================================
  Files           658      659    +1     
  Lines         22330    22378   +48     
  Branches       3595     3602    +7     
=========================================
+ Hits          15949    15984   +35     
- Misses         4676     4684    +8     
- Partials       1705     1710    +5     

Impacted Files	Coverage Δ
...java/com/nedap/archie/aom/ResourceDescription.java	100.00% <ø> (ø)
...org/openehr/bmm/v2/persistence/PBmmSimpleType.java	82.35% <0.00%> (-5.89%)	⬇️
...java/com/nedap/archie/rm/composition/Activity.java	45.16% <ø> (ø)
...va/com/nedap/archie/rminfo/ArchieRMInfoLookup.java	86.99% <ø> (-0.06%)	⬇️
...penehr/referencemodels/BuiltinReferenceModels.java	84.90% <ø> (ø)
.../java/com/nedap/archie/json/JSONSchemaCreator.java	90.07% <72.72%> (-3.52%)	⬇️
...ava/com/nedap/archie/json/JsonSchemaValidator.java	66.66% <100.00%> (ø)
.../nedap/archie/json/OpenEHRRmJSONSchemaCreator.java	100.00% <100.00%> (ø)
...ap/archie/serializer/odin/OdinToJsonConverter.java	50.00% <0.00%> (-1.07%)	⬇️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.