Introduce ContainerElement as SubmodelElement interface

[alexgordtop]

Is your feature request related to a problem? Please describe.
In documentation and implementation we often describe special aspects of SubmodelElements, that may contain other SubmodelElements. It would be handsome to define a corresponding interface, so that we can talk about them.

For reference / completeness checks it would be handsome to have that interface, so that a developer could easily identify all SubmodelElements, that require more attention.

Describe the solution you'd like
Introduce an interface "ContainerElement" comparable to DataElement and apply it to AnnotatedRelationshipElement, Entity, SubmodelElementCollection, SubmodelElementList.

Handsome enhancements:

• Operation "isIdShortRequired" -> returning true for all SubmodelElements except from SubmodelElementList
• Operation "getContainedElements" -> returning Elements contained (values, statements, annotations, ....)

These operations should be seen as recommendations to SDK implementations, what they could provide as convenience operations.

Interface and operations have no effect on serialization.

[BirgitBoss]

TF AAS Part 1 2024-05-15

• Introduction of abstract class "ContainerElement" would be backward compatible
• it might make Value-Only explanation easier
• to include operations would break concept of Part 1: there are no operations in classes so far ==> do not add operations here
• not necessarily impact on existing implementations, only for those who reflect also all abstract classes etc.
  ==> Decision Proposal: accept

[BirgitBoss]

Workstream AAS Spec 2024-06-13
Approved to add an abstract class "ContainerElement". These classes will inherit from this class:

• AnnotatedRelationshipElement,
• Entity,
• SubmodelElementCollection,
• SubmodelElementList

Operation might need to be reconsidered later to be added as well

[BirgitBoss]

compare to #434: removing abstract class was considered to be risky to change. So I wonder whether introducing a new abstract class has the same effect.

[BirgitBoss]

2024-11-27 TF Metamodel
reconfirm that we want to add this abstract class but do not want to remove abstract class HasKind

If users of a SDK use an abstract class it is not backward compatible if the class is removed
Adding a new class is different because those SDKs not supporting the new class users would still be able to create valid models

key type enumeration needs to be extended by the new abstract class (similar to DataElement and SubmodelElement): this could lead to incompatibility. If V3.1 application uses new ContainerElement but a V3.0 application consumes it then the V3.0 application would not be able to handle this and throws serialization error.

The following options:

• do not extend enumeration (because abstract classes should be used if possible anyway), but would be inconsistent to other abstract classes + introduce new abstract class
• introduce new abstrract class with 4.x and not with 3.x
• only introduce enumeration called "AasContainerElements" and add it to https://admin-shell-io.github.io/aas-specs-antora/IDTA-01001/v3.1/spec-metamodel/referencing.html#model-for-refs-keys

Solution 3 can also be combined with the other two solutions