Allow cardinality keyword for multiple attributes

Description

Cardinality has become a non-mandatory property, i.e. it is not necessary to use it if it is not being constrained. In order to identify multiple attribute object (or to set the new is_container attribute) while parsing an ADL file without requiring a reference model definition, it becomes necessary to include a marker at ADL to identify those nodes.

Original discussion thread:
http://www.openehr.org/mailarchives/openehr-implementers/msg00999.html

Activity

Show:
Thomas Beale
October 6, 2020, 11:31 AM

Well ADL doesn’t know anything about BMM - the only assumption that is made is that there must be some formal representation of the RM somewhere, such that class/type names, attribute names, cardinalities are known. This can be XSD, XMI or whatever - that is up to the tools.

To have an archetype be standalone, i.e. with no RM, it has to do two things:

  • include all the unconstrained RM classes and attributes connected to the archetype’s root class - this will often make the archetype significantly bigger than a ‘normal’ archetype.

  • be in flattened form, with all cardinality, occurrences, etc included

THere is no reason not to allow this, but we have not described the difference very well in the specs. I’m happy to do so. I think however, that such standalone archetypes have to either be marked as some kind of OPT (keyword = ‘operational_template’) or something else that indicates it is not only flattened, but contains RM classes as well.

Pieter Bos
October 6, 2020, 11:51 AM

You can still parse archetypes, just you will not know some things about some objects and attributes that you may need when working with them later.

Specific to how the ‘some formal representation’ works in Archie, you can easily add your own BMM files, and parse, validate and flatten the archetypes using those with the public API. I’ll add how to do that to the documentation soon.
If you have a model implemented as java classes, Archie has a reflection based metamodel representation you can use. It’s also possible to implement an entirely different mechanism if you need that by just implementing an abstraction layer, and the validator, flattener and OPT generator will work - although some other tools such as the example instance generator require a full BMM model.

Pieter Bos
November 2, 2020, 11:55 AM

In the change log this has been supposedly done in 2.0.0. However, it is not currently part of the specification. Has it been reverted after that
Should I move this to ADL 3.0.0 for now, or keep it here?

Thomas Beale
November 3, 2020, 3:26 PM

I vaguely remember eventually not doing it, and so it would be an error that it is in the change log - I can remove that easily enough of course. I suggest that we push this to ADL 3.x or a higher ADL 2.x since to really do it properly needs to be on the basis I mention above, i.e. that there could be archetypes that are ‘standalone’ and effectively operate as RM schemas, i.e. instead of BMMs. But we’d need to document that fairly extensively, because its a different approach to the basis of the current specs - notwithstanding the fact that the UPV team have it working. It could certainly be made to work, but it is a fair bit more complex than the innocent change originally suggested.

Pieter Bos
November 4, 2020, 12:57 PM

I moved everything that’s not in 2.2.0 or 2.3.0 to 3.0.0 for now, so we can decide later in which specific version it should go.

Reporter

David Moner

Raised By

David Moner

Components

Affects versions

Configure