model: Enforce constraints
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
: Ifself.parent.resolve(new_value)
does not throw a KeyError exception and returns another Object thanself
, 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 onasset
. -
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)