Lehrstuhl für Informations- und Automatisierungssysteme issueshttps://git.rwth-aachen.de/groups/acplt/-/issues2020-04-14T15:03:51+02:00https://git.rwth-aachen.de/acplt/pyi40aas/-/issues/65adapter: Re-publish reader/writer functions and relevant classes from adapter...2020-04-14T15:03:51+02:00Michael Thiesadapter: Re-publish reader/writer functions and relevant classes from adapter.json and adapter.xml modulesImports of the (de)serialization functions should look like
```python
from aas.adapter.json import write_aas_json_file, read_json_aas_file
```
instead of
```python
from aas.adapter.json.json_serialization import write_aas_json_file
from ...Imports of the (de)serialization functions should look like
```python
from aas.adapter.json import write_aas_json_file, read_json_aas_file
```
instead of
```python
from aas.adapter.json.json_serialization import write_aas_json_file
from aas.adapter.json.json_deserialization import read_json_aas_file
```
Thus, we should import all classes of the "public interface" in the `aas.adpater.json.__init__` and `aas.adapter.xml.__init__` modules.https://git.rwth-aachen.de/acplt/pyi40aas/-/issues/66test: cover serialization and deserialization of formulas2020-04-20T09:17:53+02:00Leon Mauritz Möllertest: cover serialization and deserialization of formulasThe serialization and deserialization of [`Formula`](https://git.rwth-aachen.de/acplt/pyaas/-/blob/fbe3f911a5d0c7acd8cc4c5114c0c499b4ba0eca/aas/model/base.py#L712)s is not tested by the current examples.
Thus lines 481-495 of the `json_d...The serialization and deserialization of [`Formula`](https://git.rwth-aachen.de/acplt/pyaas/-/blob/fbe3f911a5d0c7acd8cc4c5114c0c499b4ba0eca/aas/model/base.py#L712)s is not tested by the current examples.
Thus lines 481-495 of the `json_deserilization`, lines 169-173 of the `json_serialization` and lines 213-219 of the `xml_serialization` are not covered.https://git.rwth-aachen.de/acplt/pyi40aas/-/issues/67Add XML checks for compliance tool including tests2020-04-30T11:03:33+02:00Torben MinyAdd XML checks for compliance tool including testsAlpha Release 0.1.0Torben MinyTorben Minyhttps://git.rwth-aachen.de/acplt/pyi40aas/-/issues/68Add AASX checks for compliance tool including tests2020-11-06T10:53:50+01:00Torben MinyAdd AASX checks for compliance tool including testshttps://git.rwth-aachen.de/acplt/pyi40aas/-/issues/69examples: Add tutorial for writing and reading AASX packages2021-02-10T17:46:34+01:00Michael Thiesexamples: Add tutorial for writing and reading AASX packageshttps://git.rwth-aachen.de/acplt/pyi40aas/-/issues/70readme: Explain how to use compliance tool2020-05-19T12:33:45+02:00Michael Thiesreadme: Explain how to use compliance tool* We could just refer to the `--help` command
* If there's more to explain, we should probably create a new `README.md` file in `aas/compliance_tool/` and link to it* We could just refer to the `--help` command
* If there's more to explain, we should probably create a new `README.md` file in `aas/compliance_tool/` and link to itAlpha Release 0.1.0https://git.rwth-aachen.de/acplt/pyi40aas/-/issues/71compliance-tool: Remove hard-coded path of XML and JSON schema2020-04-30T11:03:33+02:00Michael Thiescompliance-tool: Remove hard-coded path of XML and JSON schemaSince the tests are not installed in a deployment environment, the hard-coded path in the compliance tool of the XML and JSON Schema in the `test` directory will not be valid.
Instead, we should allow users to download the Schema files ...Since the tests are not installed in a deployment environment, the hard-coded path in the compliance tool of the XML and JSON Schema in the `test` directory will not be valid.
Instead, we should allow users to download the Schema files themselves (from wherever) and tell the tool about their location, e.g. as an additional cli option.Alpha Release 0.1.0https://git.rwth-aachen.de/acplt/pyi40aas/-/issues/72adapter.xml: Check serialization of `annotation` in `AnnotatedRelationshipEle...2020-05-07T14:04:40+02:00Sebastian Heppners.heppner@iat.rwth-aachen.deadapter.xml: Check serialization of `annotation` in `AnnotatedRelationshipElement`According to the metamodel, it should be of type `DataElement`, while we (de)-serialize as `Reference`. This is correct to the current XSD-Schema, since there is currently no `dataElement_t`, but it will probably get added with the new v...According to the metamodel, it should be of type `DataElement`, while we (de)-serialize as `Reference`. This is correct to the current XSD-Schema, since there is currently no `dataElement_t`, but it will probably get added with the new version of the schema, we should check it then.https://git.rwth-aachen.de/acplt/pyi40aas/-/issues/74adapter.xml: Apply customizing pattern with class methods of json_deserializa...2020-10-28T09:26:32+01:00Michael Thiesadapter.xml: Apply customizing pattern with class methods of json_deserialization to xml_deserializationIn the `aas.adapter.json.json_deserialization` we introduced an elegant pattern to allow customizing the parser behaviour by subclassing the `AASFromJsonDecoder` class and overriding its constructor methods. This is used by the CouchDB a...In the `aas.adapter.json.json_deserialization` we introduced an elegant pattern to allow customizing the parser behaviour by subclassing the `AASFromJsonDecoder` class and overriding its constructor methods. This is used by the CouchDB adapter for example, to construct subclasses of the normal AAS model classes.
We could apply the same pattern to the `xml_deserialization` module.https://git.rwth-aachen.de/acplt/pyi40aas/-/issues/75Change name of `timeout` parameter of update method2020-10-28T17:08:34+01:00Michael ThiesChange name of `timeout` parameter of update methodThe `timeout` is more like a "caching expiration timeout" of the object, not a timeout for the actual update.
Thus, we should rename it to avoid confusion.
Maybe we can introduce an additional (optional) timout parameter for the actual...The `timeout` is more like a "caching expiration timeout" of the object, not a timeout for the actual update.
Thus, we should rename it to avoid confusion.
Maybe we can introduce an additional (optional) timout parameter for the actual update (e.g. the HTTP timeout for the HTTP client and CouchDB client).Stable library APIhttps://git.rwth-aachen.de/acplt/pyi40aas/-/issues/78couchdb: Implement `update()` and `commit()` for all CouchDB objects2020-11-10T10:15:27+01:00Michael Thiescouchdb: Implement `update()` and `commit()` for all CouchDB objectsSebastian Heppners.heppner@iat.rwth-aachen.deSebastian Heppners.heppner@iat.rwth-aachen.dehttps://git.rwth-aachen.de/acplt/pyi40aas/-/issues/80Missing `jsonschema` in `requirements.txt`2020-06-14T22:10:09+02:00Sebastian Heppners.heppner@iat.rwth-aachen.deMissing `jsonschema` in `requirements.txt`As far as I see, it is only used in the tests, though, so does it need to be added to the requirements?As far as I see, it is only used in the tests, though, so does it need to be added to the requirements?https://git.rwth-aachen.de/acplt/pyi40aas/-/issues/81aasx: Fix handling of File objects which refer to external URLs2020-11-06T10:53:50+01:00Michael Thiesaasx: Fix handling of File objects which refer to external URLsIt's currently unclear, what kind of values a `File` object may contain and how they should be interpreted. Probably, they are allowed to hold a full URL which refers to some webserver etc. as an alternative to relative and absolute path...It's currently unclear, what kind of values a `File` object may contain and how they should be interpreted. Probably, they are allowed to hold a full URL which refers to some webserver etc. as an alternative to relative and absolute paths (`./some_file.pdf` resp. `/some/path/to/some_file.pdf`), which refer to a local file.
We currently assume that all `File` objects within an AASX package refer to a supplementary file within that package. Thus, reading an AASX package file fails when it contains a `File` object refering to an external file via URL.
To fix that, we should distinguish between local and external references. However, currently the semantics of the `File.value` attribute's values are not clear from the standard (DotAAS), so we can only guess that the existence of the URL schema is the correct criterion.https://git.rwth-aachen.de/acplt/pyi40aas/-/issues/82XSD: prohibit empty strings for mandatory attributes2021-01-04T14:15:36+01:00Leon Mauritz MöllerXSD: prohibit empty strings for mandatory attributesThe current XSD Schema (v2.0.1) allows empty strings for mandatory values like `mimeType` of `blob_t` or `valueType` of `property_t`. This is because their types are given as `string`, which allows empty strings by default.
Possible fi...The current XSD Schema (v2.0.1) allows empty strings for mandatory values like `mimeType` of `blob_t` or `valueType` of `property_t`. This is because their types are given as `string`, which allows empty strings by default.
Possible fixes would be defining their minimum length as 1 or explicitely defining their allowed values. The latter would be quite a long list for `mimeType`, but certainly possible for `valueType`.https://git.rwth-aachen.de/acplt/pyi40aas/-/issues/83model: ReferenceElement.value should have type Reference instead of AASReference2020-10-28T16:59:11+01:00Michael Thiesmodel: ReferenceElement.value should have type Reference instead of AASReferenceDotAAS describes the `value` attribute as follows:
> Reference to any other referable element of the same of any other AAS or a reference to an external object or entity.
Thus, References to other objects/entities than AAS objects are ...DotAAS describes the `value` attribute as follows:
> Reference to any other referable element of the same of any other AAS or a reference to an external object or entity.
Thus, References to other objects/entities than AAS objects are also allowed.
This needs to be fixed in the deserialization adapters as well.ahttps://git.rwth-aachen.de/acplt/pyi40aas/-/issues/85Improved update()/commit() functionality2020-11-02T09:16:47+01:00Michael ThiesImproved update()/commit() functionalityWe plan a full redesign of the `update()`/`commit()` functionality of AAS objects for synchronization with an external data source.
* Instead of overriding these functions for different data sources, all `Referable` objects will include...We plan a full redesign of the `update()`/`commit()` functionality of AAS objects for synchronization with an external data source.
* Instead of overriding these functions for different data sources, all `Referable` objects will include a `source` attribute with an URI representation of their data source. The URI's schema is used to determine the correct backend/client.
* `update()` and `commit()` should always effect the object itself and all (recursively) included objects
* If the object itself has no data source/backend itself, the next higher object with a data source is used to update the object's data.
* After the update, all included objects that are linked with an own data source are updated recursively in a top-down manner.
* An object is always committed to its own data source and the data sources of all its ancestors in the object hierarchy.
* The included objects are committed recursively. (TODO: Define order of committing.)Stable library APISebastian Heppners.heppner@iat.rwth-aachen.deSebastian Heppners.heppner@iat.rwth-aachen.dehttps://git.rwth-aachen.de/acplt/pyi40aas/-/issues/87REST-API: vagueness/issues in specification2020-09-29T14:55:18+02:00Leon Mauritz MöllerREST-API: vagueness/issues in specificationThis is a collection of vagueness and issues of the [REST API specification](https://app.swaggerhub.com/apis/Plattform_i40/AssetAdministrationShell-REST-API/v1):
- It is unclear how exactly the [depth parameter](https://app.swaggerhub.co...This is a collection of vagueness and issues of the [REST API specification](https://app.swaggerhub.com/apis/Plattform_i40/AssetAdministrationShell-REST-API/v1):
- It is unclear how exactly the [depth parameter](https://app.swaggerhub.com/apis/Plattform_i40/AssetAdministrationShell-REST-API/v1#/Asset%20Administration%20Shell%20Interface/RetrieveAssetAdministrationShell) should behave, or more precisely, which effect the possible values `core`, `deep`, `embedded` and `resolve` should have on the returned object.
- The [AAS respository interface](https://app.swaggerhub.com/apis/Plattform_i40/AssetAdministrationShell-REST-API/v1#/Asset%20Administration%20Shell%20Repository%20Interface/RetrieveAssetAdministrationShellFromRepository) lacks specification.
- The response format is not specified for routes [`/submodel/values`](https://app.swaggerhub.com/apis/Plattform_i40/AssetAdministrationShell-REST-API/v1#/Submodel%20Interface/RetrieveSubmodelAsValueObject) and [`/submodel/table`](https://app.swaggerhub.com/apis/Plattform_i40/AssetAdministrationShell-REST-API/v1#/Submodel%20Interface/RetrieveSubmodelAsTable).
- Does the parameter [`identification.id`](https://app.swaggerhub.com/apis/Plattform_i40/AssetAdministrationShell-REST-API/v1#/Asset%20Administration%20Shell%20Interface/RetrieveAllSubmodels) contain the whole `identification` object or just the id attribute? Or does it work like a **str in str** filter?
- Syntax and semantics are unspecified for parameter `filter` of [`/aas/views`](https://app.swaggerhub.com/apis/Plattform_i40/AssetAdministrationShell-REST-API/v1#/Asset%20Administration%20Shell%20Interface/RetrieveAllViews).https://git.rwth-aachen.de/acplt/pyi40aas/-/issues/88Inability to test for parameter `relative_path` in calls of `backends.Backend...2020-10-28T17:08:35+01:00Sebastian Heppners.heppner@iat.rwth-aachen.deInability to test for parameter `relative_path` in calls of `backends.Backend.update_object()` and `backends.Backend.commit_object()` from `model.base.Referable` using `unittest.mock.Mock`Especially during execution of the `model.base.Referable.commit()` function, the `relative_path` variable is built iteratively by traversing the Referable-tree. Whenever there is a nonempty source, the `backends.Backend.commit_object()` ...Especially during execution of the `model.base.Referable.commit()` function, the `relative_path` variable is built iteratively by traversing the Referable-tree. Whenever there is a nonempty source, the `backends.Backend.commit_object()` function is called with the current `relative_path`. Therefore, the `relative_path` variable is likely to change after a call. This is impractical, because `unittest.mock.call` seems to only log a reference to the variables that were used in that call, rather than saving a duplicate of the current state of those variables during function call.
Here is a minimal example that shows this behavior:
```
from unittest import mock
test_mock = mock.Mock()
test_parameter = ["only_entry_of_this_list"]
test_mock(argument=test_parameter)
test_parameter.append("another_entry_of_this_list")
test_mock.assert_has_calls([mock.call(argument=["only_entry_of_this_list"])])
```
leads to:
```
AssertionError: Calls not found.
Expected: [call(argument=['only_entry_of_this_list'])]
Actual: [call(argument=['only_entry_of_this_list', 'another_entry_of_this_list'])]
```
Therefore, it is impossible to check, if the `relative_path` has been correct during the time of the function call, using the `unittest.mock.Mock`-object.
While I have reviewed with the debugger, that the function gets called with the correct `relative_path` at each time, I don't see a way to "prove it" using unittests, without altering the actual code to allow for testing, which in my opinion shouldn't really be done.Sebastian Heppners.heppner@iat.rwth-aachen.deSebastian Heppners.heppner@iat.rwth-aachen.dehttps://git.rwth-aachen.de/acplt/pyi40aas/-/issues/90model: dataType of IEC61360ConceptDescription should be optional2020-10-07T17:17:51+02:00Torben Minymodel: dataType of IEC61360ConceptDescription should be optional**EDIT (MT)**: This is an issue in our Metamodel implementation. It must also be fixed in the deserialization and serialization accordingly.**EDIT (MT)**: This is an issue in our Metamodel implementation. It must also be fixed in the deserialization and serialization accordingly.https://git.rwth-aachen.de/acplt/pyi40aas/-/issues/92compliance_tool: Use pretty-printing in example files2020-10-07T10:45:28+02:00Michael Thiescompliance_tool: Use pretty-printing in example filesThe compliance_tool should use the `pretty_print=True` resp. `indent=4` for the XML/JSON serializers when creating example files.
This way, it's easier to manually inspect the resulting files and a possible deserializer errors are easie...The compliance_tool should use the `pretty_print=True` resp. `indent=4` for the XML/JSON serializers when creating example files.
This way, it's easier to manually inspect the resulting files and a possible deserializer errors are easier to locate by their line numbers.Torben MinyTorben Miny