Lehrstuhl für Informations- und Automatisierungssysteme issueshttps://git.rwth-aachen.de/groups/acplt/-/issues2019-11-29T09:52:03+01:00https://git.rwth-aachen.de/acplt/pyi40aas/-/issues/10model: Implement Magic dict-list-thingy2019-11-29T09:52:03+01:00Michael Thiesmodel: Implement Magic dict-list-thingyA magic dict of `str` → `Referable` that can be initialized from a list of `Referable`s and can yield a magic pseudo list of its values, which also allows adding and removing values from the dict.
This is required by #8A magic dict of `str` → `Referable` that can be initialized from a list of `Referable`s and can yield a magic pseudo list of its values, which also allows adding and removing values from the dict.
This is required by #8https://git.rwth-aachen.de/acplt/pyi40aas/-/issues/9model: Implement Registry and Reference.get()2019-12-03T10:17:14+01:00Michael Thiesmodel: Implement Registry and Reference.get()* Add `AbstractRegistry` (with `lookup()` method), `AbstractObjectStore` (inheriting from `AbstractRegistry`, with `add` and `remove` methods) and `DictObjectStore` (inherting from `AbstractObjectStore`)
* Add `Reference.get(registry: Ab...* Add `AbstractRegistry` (with `lookup()` method), `AbstractObjectStore` (inheriting from `AbstractRegistry`, with `add` and `remove` methods) and `DictObjectStore` (inherting from `AbstractObjectStore`)
* Add `Reference.get(registry: AbstractRegistry)` method
* Add testshttps://git.rwth-aachen.de/acplt/pyi40aas/-/issues/8model: Add Namespace class and resolve functionality2019-12-03T09:59:41+01:00Michael Thiesmodel: Add Namespace class and resolve functionality* [x] Add an abstract class `Namespace` with method `get_referable()`
* [x] Make relevant classes inherit from `Namespace`
* [x] Convert lists of Referable objects (internally) to `NamespaceSet` (see #10)* [x] Add an abstract class `Namespace` with method `get_referable()`
* [x] Make relevant classes inherit from `Namespace`
* [x] Convert lists of Referable objects (internally) to `NamespaceSet` (see #10)https://git.rwth-aachen.de/acplt/pyi40aas/-/issues/7model: Make HasKind.kind immutable2019-12-02T14:20:58+01:00Michael Thiesmodel: Make HasKind.kind immutableThis is a proposal to make handling of objects and enforcing of constraints more safe. Idea: A template-object should never be converted to an instance-object (without explicit creation of a new object) and vice versa. This would resolve...This is a proposal to make handling of objects and enforcing of constraints more safe. Idea: A template-object should never be converted to an instance-object (without explicit creation of a new object) and vice versa. This would resolve the issue with constraint AASd-008 (see #6).
We could also consider making other, more specific attributes immutable.
Implementation is possible using a property and a hidden attribute (`_kind`).https://git.rwth-aachen.de/acplt/pyi40aas/-/issues/6model: Enforce constraints2019-12-03T11:11:03+01:00Michael Thiesmodel: Enforce constraintsSome thoughts about the implementation of each constraint:
* [x] AASd-001: Can be enforced in initializer + property-setter, that only allows `None` values, if object has an attribute 'identification` (Yay, duck typing!)
* [x] AASd-002:...Some thoughts about the implementation of each constraint:
* [x] AASd-001: Can be enforced in initializer + property-setter, that only allows `None` values, if object has an attribute 'identification` (Yay, duck typing!)
* [x] AASd-002: Can be checked in intializer + property-setter
* [ ] (AASd-003: Oh no!)
* [x] 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.
* [x] AASd-004: We ignore this constraint and instead set `parent` upon adding to a Namespace (We should document this in the code)
* [x] AASd-005: Idea: Make the whole object immutable
* [x] AASd-006 & **AASd-007** & **AASd-012**: Let's ignore this, since we currently don't know, how `valueId` actually works
* [x] 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.
* [x] 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.)
* [x] AASd-014: We can ensure this by making `entityType` an automatically-computed property depending on `asset`.
* [x] AASd-009: Let's ignore this constraint to make programming with this class easier (security is not supported since security is not correct)
* [x] AASd-010: I don't see, how we could check this. (security is not supported since security is not correct)
* [x] 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)
* [x] 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)https://git.rwth-aachen.de/acplt/pyi40aas/-/issues/5model: Add constraints to Class docstrings2019-11-27T15:32:26+01:00Michael Thiesmodel: Add constraints to Class docstringsTorben MinyTorben Minyhttps://git.rwth-aachen.de/acplt/pyi40aas/-/issues/4model: Add docstring for intializers, including argument description2019-11-27T14:42:29+01:00Michael Thiesmodel: Add docstring for intializers, including argument description* The argument description should be copied from the (super-)class' attribute description, extended by " (from \<Classname\>)"
* It should be mentioned, what *should* be done typically with the object after constructing it (e.g. "Should ...* The argument description should be copied from the (super-)class' attribute description, extended by " (from \<Classname\>)"
* It should be mentioned, what *should* be done typically with the object after constructing it (e.g. "Should be added to a Submodel or SubmodelElementCollection via `add_element()`"). Probably we should add a TODO here, until the interface for adding elements etc. is fixed.Torben MinyTorben Minyhttps://git.rwth-aachen.de/acplt/pyi40aas/-/issues/3Check order of intializer arguments of similar classes2019-12-02T14:23:01+01:00Michael ThiesCheck order of intializer arguments of similar classesE.g. different `SubmodelElement` subclasses should have a similiar order of initializer arguments for less fuckup when using them in code.E.g. different `SubmodelElement` subclasses should have a similiar order of initializer arguments for less fuckup when using them in code.Leon Mauritz MöllerLeon Mauritz Möllerhttps://git.rwth-aachen.de/acplt/pyi40aas/-/issues/2CI: Add linter2019-11-27T10:47:16+01:00Michael ThiesCI: Add linterhttps://git.rwth-aachen.de/acplt/pyi40aas/-/issues/1Check model classes for completness according to VWSiD V2.02019-12-09T13:06:15+01:00Michael ThiesCheck model classes for completness according to VWSiD V2.0Includes checking for updated descriptions
See here: https://www.plattform-i40.de/PI40/Redaktion/DE/Downloads/Publikation/Details-of-the-Asset-Administration-Shell-Part1.htmlIncludes checking for updated descriptions
See here: https://www.plattform-i40.de/PI40/Redaktion/DE/Downloads/Publikation/Details-of-the-Asset-Administration-Shell-Part1.html