PyI40AAS issueshttps://git.rwth-aachen.de/acplt/pyi40aas/-/issues2021-01-20T11:08:21+01:00https://git.rwth-aachen.de/acplt/pyi40aas/-/issues/122XSD: change `xs:sequence` to `xs:all`2021-01-20T11:08:21+01:00Leon Mauritz MöllerXSD: change `xs:sequence` to `xs:all`The XSD currently uses `xs:sequence` to define attributes of types. This requires the children of elements in XML documents to be in the exact same order as defined in the XSD, which results in the unnecessary work of re-ordering code-bl...The XSD currently uses `xs:sequence` to define attributes of types. This requires the children of elements in XML documents to be in the exact same order as defined in the XSD, which results in the unnecessary work of re-ordering code-blocks in serialization adapters, as seen in !67. Changing `xs:sequence` to `xs:all` would remove this limitation, allowing children in any order to be valid against the schema.
On the other hand I could see why you would want a certain order of elements. For example when manually inspecting XML documents (which can get quite large), a fixed order of elements would make objects easier to grasp.
But then again, you would most likely use XPath or good XML viewers to view such documents anyways.
What's your opinion on this?
forwarded to DotAAS-Group: [Issue 20](https://github.com/admin-shell-io/aas-specs/issues/20)https://git.rwth-aachen.de/acplt/pyi40aas/-/issues/116JSON schema: missing DataElement type2021-04-10T17:34:32+02:00Leon Mauritz MöllerJSON schema: missing DataElement typeThe JSON schema currently doesn't have any type for `DataElement`s. We suggest to add this missing type, so schema validators can spot incorrectly placed `SubmodelElement`s, e.g. where a `DataElement` is expected.
Additionally, the XML...The JSON schema currently doesn't have any type for `DataElement`s. We suggest to add this missing type, so schema validators can spot incorrectly placed `SubmodelElement`s, e.g. where a `DataElement` is expected.
Additionally, the XML Schema Definition has such a type, so adding this type would improve the consistency between the two schemas.
forwarded to DotAAS-Group: [Issue 21](https://github.com/admin-shell-io/aas-specs/issues/21)Leon Mauritz MöllerLeon Mauritz Möllerhttps://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/57XSD: unneccesary wrapper elements2021-01-20T11:07:04+01:00Sebastian Heppners.heppner@iat.rwth-aachen.deXSD: unneccesary wrapper elementsThe current version of the schema (v3.0 RC01) has unnecessary wrapper elements around each Submodel Element and Data Element.
forwarded to DotAAS-Group: [Issue 22](https://github.com/admin-shell-io/aas-specs/issues/22)
### Submodel E...The current version of the schema (v3.0 RC01) has unnecessary wrapper elements around each Submodel Element and Data Element.
forwarded to DotAAS-Group: [Issue 22](https://github.com/admin-shell-io/aas-specs/issues/22)
### Submodel Element
```xml
<submodelElements>
<submodelElement> <!-- this is unnecessary -->
<entity/>
</submodelElement>
<submodelElement> <!-- this is unnecessary -->
<property/>
</submodelElement>
[...]
</submodelElements>
```
We suggest the removal of the wrapper element:
```xml
<submodelElements>
<entity/>
<property/>
[...]
</submodelElements>
```
### Data Element
```xml
<annotations>
<dataElement> <!-- this is unnecessary -->
<property/>
</dataElement>
<dataElement> <!-- this is unnecessary -->
<range/>
</dataElement>
[...]
</annotations>
```
Again, we suggest the removal of the wrapper element:
```xml
<annotations>
<property/>
<range/>
[...]
</annotations>
```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>
```https://git.rwth-aachen.de/acplt/pyi40aas/-/issues/28model: Operation should be a Namespace with three NameSpaceSets for its Opera...2021-01-12T13:42:15+01:00Michael Thiesmodel: Operation should be a Namespace with three NameSpaceSets for its OperationVariablesThis implementation has been reverted in https://git.rwth-aachen.de/acplt/pyi40aas/-/commit/0fee9b12537ed7b49ce3586d870bbc9cca93f636. We are currently awaiting feedback on this.
If this class stays in the metamodel, we could remove `Ope...This implementation has been reverted in https://git.rwth-aachen.de/acplt/pyi40aas/-/commit/0fee9b12537ed7b49ce3586d870bbc9cca93f636. We are currently awaiting feedback on this.
If this class stays in the metamodel, we could remove `OperationVariable` in our implementation and attach `SubmodelElement`s to the `Operation` directly, so we can make `Operation` a `Namespace`.
Adapters would then just "emulate" `OperationVariable`s.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.