Lehrstuhl für Informations- und Automatisierungssysteme issueshttps://git.rwth-aachen.de/groups/acplt/-/issues2020-03-25T13:08:58+01:00https://git.rwth-aachen.de/acplt/pyi40aas/-/issues/22model.adapter: Serialization for XML2020-03-25T13:08:58+01:00Torben Minymodel.adapter: Serialization for XMLSebastian Heppners.heppner@iat.rwth-aachen.deSebastian Heppners.heppner@iat.rwth-aachen.dehttps://git.rwth-aachen.de/acplt/pyi40aas/-/issues/21model.adapter: Serialization for JSON2019-12-20T14:50:44+01:00Torben Minymodel.adapter: Serialization for JSONTorben MinyTorben Minyhttps://git.rwth-aachen.de/acplt/pyi40aas/-/issues/20model.base.LangStringSet: change class structure to fit the explanation in Do...2019-12-02T15:09:49+01:00Sebastian Heppners.heppner@iat.rwth-aachen.demodel.base.LangStringSet: change class structure to fit the explanation in DotAASv2.0 betterAccording to DotAASv2.0, the LangStringSet is "A set of strings, each annotated by the language of the string. The meaning of the string
in each language shall be the same."
Right now, its content is just a set of LangStrings.
Wouldn'...According to DotAASv2.0, the LangStringSet is "A set of strings, each annotated by the language of the string. The meaning of the string
in each language shall be the same."
Right now, its content is just a set of LangStrings.
Wouldn't it make more sense, if its content was a set of pairs of a LangString, together with a string that "annotates the language" (or even an Enum of the different language IDs or sth) instead?
The way I understand the DotAASv2.0, is that LangStrings are nothing but strings (in a specified language) but it doesn't seem like there is a way for anyone to know which language it is written in.https://git.rwth-aachen.de/acplt/pyi40aas/-/issues/19model: Remove Key.type2021-01-12T13:42:20+01:00Michael Thiesmodel: Remove Key.typeThis attribute is not required for resolving references.This attribute is not required for resolving references.https://git.rwth-aachen.de/acplt/pyi40aas/-/issues/16model: Initializer of AssetAdministrationShell misses `identification` parameter2019-12-02T15:18:17+01:00Michael Thiesmodel: Initializer of AssetAdministrationShell misses `identification` parameterhttps://git.rwth-aachen.de/acplt/pyi40aas/-/issues/15add license2019-12-11T11:19:39+01:00Leon Mauritz Mölleradd licensehttps://git.rwth-aachen.de/acplt/pyi40aas/-/issues/14model: Create subclasses of submodelElementCollection2019-11-27T15:15:43+01:00Torben Minymodel: Create subclasses of submodelElementCollectioncreate two sub classes of submodelElementCollection, one with ordered list and one with unordered list for submodel elementscreate two sub classes of submodelElementCollection, one with ordered list and one with unordered list for submodel elementshttps://git.rwth-aachen.de/acplt/pyi40aas/-/issues/13model: Change List to Set for unordered attributes2019-11-27T14:07:58+01:00Torben Minymodel: Change List to Set for unordered attributesMust coordinated with #10Must coordinated with #10Torben MinyTorben Minyhttps://git.rwth-aachen.de/acplt/pyi40aas/-/issues/12model: Fix mutable default parameters2019-11-28T08:59:23+01:00Michael Thiesmodel: Fix mutable default parametersCurrently, we use lists in many places as default initializer parameters. In Python, this means, that each call to this initializer without an explicit specification of that parameter will receive a reference to the *same* list. Thus all...Currently, we use lists in many places as default initializer parameters. In Python, this means, that each call to this initializer without an explicit specification of that parameter will receive a reference to the *same* list. Thus all those objects will use the *same* list of elements; adding an element to one of the objects will also add it to all other objects.
For some of our list attributes (all lists of `Referable`s, forming `Namespace`s), this will be fixed by #8. In all other cases, we should fix this by changing the default parameter to `None` and adding the following code to the initializer:
```python
if var is None:
var = []
```
This way, we create a new list for every default-initialized object.Torben MinyTorben Minyhttps://git.rwth-aachen.de/acplt/pyi40aas/-/issues/11Add factory and / or manager module for simple construction of AASes2021-01-18T17:28:12+01:00Michael ThiesAdd factory and / or manager module for simple construction of AASesThe factory functions (which may be methods of a manager, that also includes an ObjectStore) should encapsulate all the boilerplate code required for constructing an AAS, constructing and adding a submodule, etc.The factory functions (which may be methods of a manager, that also includes an ObjectStore) should encapsulate all the boilerplate code required for constructing an AAS, constructing and adding a submodule, etc.https://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