PyI40AAS issueshttps://git.rwth-aachen.de/acplt/pyi40aas/-/issues2020-09-29T14:55:18+02:00https://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/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/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/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/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/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/52XSD-Schema: missing minOccurs="0" of element `containedElements` in type `vie...2020-02-25T08:06:23+01:00Sebastian Heppners.heppner@iat.rwth-aachen.deXSD-Schema: missing minOccurs="0" of element `containedElements` in type `view_t`Class `view` has parameter `containedElements`:
![View](/uploads/0514057d047dd557cbf2dbceb92b0fec/View.png)
of cardinality 0..*
The XSD-Schema therefore needs a `minOccurs="0"`in element `<containedElements>`.
Current version:
```
<c...Class `view` has parameter `containedElements`:
![View](/uploads/0514057d047dd557cbf2dbceb92b0fec/View.png)
of cardinality 0..*
The XSD-Schema therefore needs a `minOccurs="0"`in element `<containedElements>`.
Current version:
```
<complexType name="view_t">
<sequence>
<group ref="aas:referable"/>
<group ref="aas:hasSemantics"/>
<group ref="aas:hasDataSpecification"/>
<element name="containedElements" type="aas:containedElements_t" ></element>
</sequence>
</complexType>
```
Proposed Fix:
```
<complexType name="view_t">
<sequence>
<group ref="aas:referable"/>
<group ref="aas:hasSemantics"/>
<group ref="aas:hasDataSpecification"/>
<element maxOccurs="unbounded" minOccurs="0" name="containedElements" type="aas:containedElements_t"/>
</sequence>
</complexType>
```https://git.rwth-aachen.de/acplt/pyi40aas/-/issues/51XSD-Schema: missing minOccurs="0" of element "conceptDescriptionRefs" in type...2020-02-25T14:19:35+01:00Sebastian Heppners.heppner@iat.rwth-aachen.deXSD-Schema: missing minOccurs="0" of element "conceptDescriptionRefs" in type "conceptDictionary_t"Class `ConceptDictionary` has parameter `conceptDescription`: ![conceptDictionary](/uploads/a32d03ee11104052db45680c98650ea4/conceptDictionary.png) of cardinality 0..*.
The XSD-schema therefore needs a `minOccurs="0"`in element `<concep...Class `ConceptDictionary` has parameter `conceptDescription`: ![conceptDictionary](/uploads/a32d03ee11104052db45680c98650ea4/conceptDictionary.png) of cardinality 0..*.
The XSD-schema therefore needs a `minOccurs="0"`in element `<conceptDescriptionRefs>`.
Current Version:
```
<complexType name="conceptDictionary_t">
<sequence>
<group ref="aas:referable" />
<element name="conceptDescriptionRefs" type="aas:conceptDescriptionRefs_t"></element>
</sequence>
</complexType>
```
Suggested Fix:
```
<complexType name="conceptDictionary_t">
<sequence>
<group ref="aas:referable" />
<element maxOccurs="unbounded" minOccurs="0" name="conceptDescriptionRefs" type="aas:conceptDescriptionRefs_t"/>
</sequence>
</complexType>
```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/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/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/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/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>
```