Lehrstuhl für Informations- und Automatisierungssysteme issueshttps://git.rwth-aachen.de/groups/acplt/-/issues2020-10-28T11:52:35+01:00https://git.rwth-aachen.de/acplt/pyi40aas/-/issues/93aasx: Support AASX packages with XML + JSON parts (redundant serialization of...2020-10-28T11:52:35+01:00Michael Thiesaasx: Support AASX packages with XML + JSON parts (redundant serialization of same objects)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/96examples.data.example_aas: Missing namespace initialization for `create_examp...2020-10-13T12:24:39+02:00Sebastian Heppners.heppner@iat.rwth-aachen.deexamples.data.example_aas: Missing namespace initialization for `create_example_submodel`If you try:
```
test_submodel = create_example_submodel()
test_submodel.get_referable("ExampleProperty")
```
you recieve:
```
KeyError: 'Referable with id_short ExampleProperty not found in this namespace'
```
This function (and possi...If you try:
```
test_submodel = create_example_submodel()
test_submodel.get_referable("ExampleProperty")
```
you recieve:
```
KeyError: 'Referable with id_short ExampleProperty not found in this namespace'
```
This function (and possibly all the other `create_example...`-functions) is/are missing the creation of a `NamespaceSet` containing all the sub-elements, something like:
```
example_submodel_namespace_set = NamespaceSet(parent=example_submodel, items=[example_property, ...])
example_submodel.namespace_element_sets = [example_submodel_namespace_set]
```
Though, shouldn't these namespaces in general be created automatically with initializing the objects?https://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 Minyhttps://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/basys4.2/ccProfilesUA/-/issues/3Instanciate examples based on the full feature profile2020-07-22T19:42:04+02:00Julian Grothoffj.grothoff@plt.rwth-aachen.deInstanciate examples based on the full feature profile* [x] Use UA modelling rules to annotate CCInterfaceTypes in OPC UA with SI facet CMD and OPERATIONS interface specifications.
* [x] Set PROFILE variable based on profile parameter
* [x] Use CreateOptionalChildCallback to instanciate ...* [x] Use UA modelling rules to annotate CCInterfaceTypes in OPC UA with SI facet CMD and OPERATIONS interface specifications.
* [x] Set PROFILE variable based on profile parameter
* [x] Use CreateOptionalChildCallback to instanciate based on modelling rules
* [x] Set profile parameter via comand lineBASYS Profilehttps://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/35XSD-Schema: missing `minOccurs="0"` in element `value` of `file_t`2020-05-28T12:04:31+02:00Sebastian Heppners.heppner@iat.rwth-aachen.deXSD-Schema: missing `minOccurs="0"` in element `value` of `file_t`Class `File` has attribute `value` with cardinality `0..1`:
![File](/uploads/40386615c5291583360b796f9f51cf07/File.png)
Therefore, the XSD-Schema should have a `minOccurs="0"` in the element defintion of `value` to comply with this.
C...Class `File` has attribute `value` with cardinality `0..1`:
![File](/uploads/40386615c5291583360b796f9f51cf07/File.png)
Therefore, the XSD-Schema should have a `minOccurs="0"` in the element defintion of `value` to comply with this.
Current Version:
```
<complexType name="file_t">
<complexContent>
<extension base="aas:submodelElementAbstract_t">
<sequence>
<element name="mimeType" type="string"/>
<element name="value" type="aas:pathType_t"/>
</sequence>
</extension>
</complexContent>
</complexType>
```
Proposed Fix:
```
<complexType name="file_t">
<complexContent>
<extension base="aas:submodelElementAbstract_t">
<sequence>
<element name="mimeType" type="string"/>
<element minOccurs="0" name="value" type="aas:pathType_t"/>
</sequence>
</extension>
</complexContent>
</complexType>
```https://git.rwth-aachen.de/acplt/pyi40aas/-/issues/56XSD-Schema: group `qualifiable` definition inelegant and confusing2020-05-28T12:03:56+02:00Sebastian Heppners.heppner@iat.rwth-aachen.deXSD-Schema: group `qualifiable` definition inelegant and confusingThe current Schema uses the plural "s" for qualifiers in group `qualifiable` in a confusing way. For example a qualifiable property could look like this, when serialized according to the current schema:
```
<property>
[...]
<qualifier>
...The current Schema uses the plural "s" for qualifiers in group `qualifiable` in a confusing way. For example a qualifiable property could look like this, when serialized according to the current schema:
```
<property>
[...]
<qualifier>
<qualifiers>
<qualifier/>
</qualifiers>
<qualifiers>
<formula/>
</qualifiers>
[...]
</qualifier>
[...]
</property>
```
The wrapping `<qualifiers>` element around each inner `<qualifier>` or `<formula>` seems unneccesary. We suggest to remove it, to look like this:
```
<property>
[...]
<qualifiers>
<qualifier/>
<formula/>
[...]
</qualifiers>
[...]
</property>
```
This can be achieved by changing the current version of the XSD-Schema from:
```
<group name="qualifiable">
<sequence>
<element maxOccurs="1" minOccurs="0" name="qualifier" type="aas:constraints_t"/>
</sequence>
</group>
<complexType name="constraints_t">
<sequence>
<element maxOccurs="unbounded" minOccurs="0" name="qualifiers" type="aas:constraint_t"/>
</sequence>
</complexType>
<complexType name="constraint_t">
<choice>
<element maxOccurs="1" minOccurs="0" name="formula" type="aas:formula_t"/>
<element maxOccurs="1" minOccurs="0" name="qualifier" type="aas:qualifier_t"/>
</choice>
</complexType>
```
to our suggested fix:
```
<group name="qualifiable">
<sequence>
<element maxOccurs="1" minOccurs="0" name="qualifiers" type="aas:constraints_t"/>
</sequence>
</group>
<complexType name="constraints_t">
<sequence>
<group maxOccurs="unbounded" minOccurs="0" ref="aas:constraintGroup"/>
</sequence>
</complexType>
<group name="constraintGroup">
<choice>
<element maxOccurs="1" minOccurs="0" name="formula" type="aas:formula_t"/>
<element maxOccurs="1" minOccurs="0" name="qualifier" type="aas:qualifier_t"/>
</choice>
</group>
```https://git.rwth-aachen.de/acplt/pyi40aas/-/issues/47DotAAS: Qualifiable naming unclear/unintuitive2020-05-28T12:03:56+02:00Sebastian Heppners.heppner@iat.rwth-aachen.deDotAAS: Qualifiable naming unclear/unintuitiveAn object that is instance of class Qualifiable has a rather weird naming convention, at least to me.
`Qualifiable.qualifier` is of type `Set[constraints]`, which in term constraints are either `base.Formula` or `base.Qualifier`.
In t...An object that is instance of class Qualifiable has a rather weird naming convention, at least to me.
`Qualifiable.qualifier` is of type `Set[constraints]`, which in term constraints are either `base.Formula` or `base.Qualifier`.
In the XSD-schema, a `qualifiable` therefore has the subelement 'qualifier', which makes sense, but as a logical consequence, this
```
<element maxOccurs="1" minOccurs="0" name="qualifier" type="aas:constraints_t"/>
```
now has children with name "qualifiers"
```
<element maxOccurs="unbounded" minOccurs="0" name="qualifiers" type="aas:constraint_t"/>
```
which in turn now can either have children as "formula" or "qualifier".
```
<element maxOccurs="1" minOccurs="0" name="formula" type="aas:formula_t"/>
<element maxOccurs="1" minOccurs="0" name="qualifier" type="aas:qualifier_t"/>
```
Am I wrong to find this rather messy and unintuitive?
I would suggest to change the name of `base.Qualifiable` and its parameter `Qualifiable.qualifier` to something that isn't so easily confused with `base.Qualifier`, since they're obviously two very different things.https://git.rwth-aachen.de/acplt/pyi40aas/-/issues/48XSD-Schema: missing type "annotatedRelationshipElement_t"2020-05-28T12:03:01+02:00Sebastian Heppners.heppner@iat.rwth-aachen.deXSD-Schema: missing type "annotatedRelationshipElement_t"In type `submodelElement_t`, the `annotatedRelationshipElement` is of type `aas:relationshipElement_t`,
```
<element name="annotatedRelationshipElement" type="aas:relationshipElement_t"/>
```
which does not have the capability of stor...In type `submodelElement_t`, the `annotatedRelationshipElement` is of type `aas:relationshipElement_t`,
```
<element name="annotatedRelationshipElement" type="aas:relationshipElement_t"/>
```
which does not have the capability of storing the information of the parameter:
```
submodel.AnnotatedRelationshipElement.annotation: Optional[Set[base.AASReference[DataElement]]]
```
The type `aas:annotatedRelationshipElement_t` does not exist in the XSD-schema, so it is not just missing in `submodelElement_t`, but in general.https://git.rwth-aachen.de/acplt/pyi40aas/-/issues/49XSD-Schema: wrong type `string` of element `capability` in `submodelElement_t`2020-05-28T12:02:49+02:00Sebastian Heppners.heppner@iat.rwth-aachen.deXSD-Schema: wrong type `string` of element `capability` in `submodelElement_t`Class `Capability` inherits from `SubmodelElement`:
![capability](/uploads/86eaaff32163ae97648d9084dbb43dd7/capability.png)
Therefore, in the XSD-Schema, it should be of type `aas:submodelElementAbstract_t`, rather than of type `string`...Class `Capability` inherits from `SubmodelElement`:
![capability](/uploads/86eaaff32163ae97648d9084dbb43dd7/capability.png)
Therefore, in the XSD-Schema, it should be of type `aas:submodelElementAbstract_t`, rather than of type `string`.
Current version:
```
<element name="capability" type="string"/>
```
Proposed Fix:
```
<element name="capability" type="aas:submodelElementAbstract_t"/>
```https://git.rwth-aachen.de/acplt/pyi40aas/-/issues/50XSD-Schema: Wrong type `aas:submodelElement_t` for element `statements` in XS...2020-05-28T12:02:08+02:00Sebastian Heppners.heppner@iat.rwth-aachen.deXSD-Schema: Wrong type `aas:submodelElement_t` for element `statements` in XSD-schema type `entity_t`Class `Entity` has optional parameter `statement` with cardinality `0..*`:
![Entity](/uploads/942403a3603a3d87a7fd63b612c744a3/Entity.png)
The XSD-Schema has an element `statements` of type `aas:submodelElement_t`, whereas, it should ra...Class `Entity` has optional parameter `statement` with cardinality `0..*`:
![Entity](/uploads/942403a3603a3d87a7fd63b612c744a3/Entity.png)
The XSD-Schema has an element `statements` of type `aas:submodelElement_t`, whereas, it should rather be of type `aas:submodelElements_t`, to make it possible to have more than one statement parameter in an entity. Current version:
```
<element name="statements" type="aas:submodelElement_t"/>
```
Proposed Fix:
```
<element name="statements" type="aas:submodelElements_t"/>
```
Since the `aas:submodelElements_t` would be exactly what we want:
```
<complexType name="submodelElements_t">
<sequence>
<element maxOccurs="unbounded" minOccurs="0" name="submodelElement" type="aas:submodelElement_t"/>
</sequence>
</complexType>
```https://git.rwth-aachen.de/acplt/pyi40aas/-/issues/53XSD-Schema: Missing minOccurs="0" of element `<value>` in `<referenceElement_t>`2020-05-28T12:01:09+02:00Sebastian Heppners.heppner@iat.rwth-aachen.deXSD-Schema: Missing minOccurs="0" of element `<value>` in `<referenceElement_t>`The attribute `value` of class `referenceElement` is optional:
![ReferenceElement](/uploads/04e7c477b61aa6ae098330a878f4dc0c/ReferenceElement.png)
Therefore, the xsd-schema needs a `minOccurs="0"` there.
Current version:
```
<complexTy...The attribute `value` of class `referenceElement` is optional:
![ReferenceElement](/uploads/04e7c477b61aa6ae098330a878f4dc0c/ReferenceElement.png)
Therefore, the xsd-schema needs a `minOccurs="0"` there.
Current version:
```
<complexType name="referenceElement_t">
<complexContent>
<extension base="aas:submodelElementAbstract_t">
<sequence>
<element name="value" type="aas:reference_t"/>
</sequence>
</extension>
</complexContent>
</complexType>
```
Suggested fix:
```
<complexType name="referenceElement_t">
<complexContent>
<extension base="aas:submodelElementAbstract_t">
<sequence>
<element minOccurs="0" name="value" type="aas:reference_t"/>
</sequence>
</extension>
</complexContent>
</complexType>
```https://git.rwth-aachen.de/acplt/pyi40aas/-/issues/54XSD-Schema: Missing "minOccurs="0"" of element `<assetRef>` in `<entity_t>`2020-05-28T12:00:23+02:00Sebastian Heppners.heppner@iat.rwth-aachen.deXSD-Schema: Missing "minOccurs="0"" of element `<assetRef>` in `<entity_t>`The `asset` attribute of class `Entity` is optional:
![Entity](/uploads/da9b38386dd04765625949898bf88942/Entity.png)
Therefore, the element `<assetRef>` in `<entity_t>` misses a "minOccurs" set.
Current schema:
```
<complexType name="e...The `asset` attribute of class `Entity` is optional:
![Entity](/uploads/da9b38386dd04765625949898bf88942/Entity.png)
Therefore, the element `<assetRef>` in `<entity_t>` misses a "minOccurs" set.
Current schema:
```
<complexType name="entity_t">
<complexContent>
<extension base="aas:submodelElementAbstract_t">
<sequence>
<element name="assetRef" type="aas:reference_t"/>
<element name="entityType">
<simpleType>
<restriction base="aas:entityType_t">
<enumeration value="CoManagedEntity"/>
<enumeration value="SelfManagedEntity"/>
</restriction>
</simpleType>
</element>
<element name="statements" type="aas:submodelElement_t"/>
</sequence>
</extension>
</complexContent>
</complexType>
```
Proposed Fix:
```
<complexType name="entity_t">
<complexContent>
<extension base="aas:submodelElementAbstract_t">
<sequence>
<element minOccurs="0" name="assetRef" type="aas:reference_t"/>
<element name="entityType">
<simpleType>
<restriction base="aas:entityType_t">
<enumeration value="CoManagedEntity"/>
<enumeration value="SelfManagedEntity"/>
</restriction>
</simpleType>
</element>
<element name="statements" type="aas:submodelElement_t"/>
</sequence>
</extension>
</complexContent>
</complexType>
```https://git.rwth-aachen.de/acplt/pyi40aas/-/issues/60XSD-Schema: empty type `valueDataType_t` in IEC61360.xsd2020-05-28T11:56:27+02:00Sebastian Heppners.heppner@iat.rwth-aachen.deXSD-Schema: empty type `valueDataType_t` in IEC61360.xsdThe `complexType`: `valueDataType_t` in the IEC61360.xsd schema file is empty:
```
<complexType name="valueDataType_t"/>
```
Therefore, it is impossible, to specify value data in accordance to the schema. Suggested Fix:
```
<co...The `complexType`: `valueDataType_t` in the IEC61360.xsd schema file is empty:
```
<complexType name="valueDataType_t"/>
```
Therefore, it is impossible, to specify value data in accordance to the schema. Suggested Fix:
```
<complexType name="valueDataType_t">
<simpleContent>
<extension base="anySimpleType"/>
</simpleContent>
</complexType>
```https://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/55examples: Create example explaining how to subclass AAS model classes (esp. P...2020-05-18T14:30:32+02:00Michael Thiesexamples: Create example explaining how to subclass AAS model classes (esp. Property) for dynamic data/custom backendshttps://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.