GitLab

Some thoughts about the implementation of each constraint:

• AASd-001: Can be enforced in initializer + property-setter, that only allows None values, if object has an attribute 'identification` (Yay, duck typing!)
• AASd-002: Can be checked in intializer + property-setter
• (AASd-003: Oh no!)
• Additional constraint: Uniqueness of idShort in one Namespace: Can be checked upon adding Referable to Namespace and in property-setter of idShort: If self.parent.resolve(new_value) does not throw a KeyError exception and returns another Object than self, we do not allow the new name.
• AASd-004: We ignore this constraint and instead set parent upon adding to a Namespace (We should document this in the code)
• AASd-005: Idea: Make the whole object immutable
• AASd-006 & AASd-007 & AASd-012: Let's ignore this, since we currently don't know, how valueId actually works
• AASd-013: Let's ignore this constraint. A range could be unlimited to both ends. Additionally, Property does not enforce to have a value either.
• AASd-008: Can be enforced in initializer + property-setter. However, we cannot ensure that the SubmodelElement's kind is not changed afterwards. (A possible solution for this is proposed in #7 (closed).)
• AASd-014: We can ensure this by making entityType an automatically-computed property depending on asset.
• AASd-009: Let's ignore this constraint to make programming with this class easier (security is not supported since security is not correct)
• AASd-010: I don't see, how we could check this. (security is not supported since security is not correct)
• AASd-011: Can be enforced in initializer + property-setter, but requires some annoying tree traversal (using parent). (security is not supported since security is not correct)
• AASd-015: Can be enforced in initializer + property-setter, but requires some annoying tree traversal (using parent). (security is not supported since security is not correct)