Lehrstuhl für Informations- und Automatisierungssysteme issueshttps://git.rwth-aachen.de/groups/acplt/-/issues2021-01-25T14:25:23+01:00https://git.rwth-aachen.de/acplt/pyi40aas/-/issues/128Add reprs for classes GDay, GMonth, GMonthDay, GYearMonth, GYear2021-01-25T14:25:23+01:00Igor GarmaevAdd reprs for classes GDay, GMonth, GMonthDay, GYearMonth, GYearAdd reprs for classes GDay, GMonth, GMonthDay, GYearMonth, GYear in model/datatypes.pyAdd reprs for classes GDay, GMonth, GMonthDay, GYearMonth, GYear in model/datatypes.pyhttps://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/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/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/106examples.tutorial_dynamic_model: Adapt tutorial for new Referable.update/comm...2021-01-12T13:43:08+01:00Sebastian Heppners.heppner@iat.rwth-aachen.deexamples.tutorial_dynamic_model: Adapt tutorial for new Referable.update/commit-functionalityhttps://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/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/76Add HTTP API Server Implementation2021-01-12T13:39:11+01:00Michael ThiesAdd HTTP API Server Implementation… according to the current draft of DotAAS Part 2.
Our API Spec: https://git.rwth-aachen.de/leon.moeller/pyi40aas-oas… according to the current draft of DotAAS Part 2.
Our API Spec: https://git.rwth-aachen.de/leon.moeller/pyi40aas-oasBaSys interoperabilityLeon Mauritz MöllerLeon Mauritz Möllerhttps://git.rwth-aachen.de/acplt/pyi40aas/-/issues/77Add HTTP API Client2021-01-12T13:39:07+01:00Michael ThiesAdd HTTP API Client… according to the current draft of DotAAS Part 2.
The client should allow to create "connected objects", which behave just like normal PyI40AAS objects but reflect the server's objects via their `update()` and `commit()` methods.… according to the current draft of DotAAS Part 2.
The client should allow to create "connected objects", which behave just like normal PyI40AAS objects but reflect the server's objects via their `update()` and `commit()` methods.BaSys interoperabilityhttps://git.rwth-aachen.de/acplt/pyi40aas/-/issues/120aasx.writer: Add searching and adding referenced ConceptDescriptions to write...2021-01-12T13:38:58+01:00Michael Thiesaasx.writer: Add searching and adding referenced ConceptDescriptions to write_aashttps://git.rwth-aachen.de/acplt/pyi40aas/-/issues/112adapter: Allow passing a list of Identifiable objects to be ignored to read_a...2021-01-12T13:38:29+01:00Michael Thiesadapter: Allow passing a list of Identifiable objects to be ignored to read_aas_*_file()This feature is required by the AASXReader to silently ignore objects that are serialized redundantly in different formats (XML / JSON).
It should be implemented as an additional optional parameter, taking a `Set[Identifier]`.This feature is required by the AASXReader to silently ignore objects that are serialized redundantly in different formats (XML / JSON).
It should be implemented as an additional optional parameter, taking a `Set[Identifier]`.https://git.rwth-aachen.de/acplt/pyi40aas/-/issues/17model: Subclass Identifier for different id types and use native types for id2021-01-12T13:37:57+01:00Michael Thiesmodel: Subclass Identifier for different id types and use native types for idStable library APIhttps://git.rwth-aachen.de/acplt/pyi40aas/-/issues/18model: Merge KeyType and IdentifierType2021-01-12T13:37:45+01:00Michael Thiesmodel: Merge KeyType and IdentifierTypeStable library APIhttps://git.rwth-aachen.de/acplt/pyi40aas/-/issues/73adapter.json: Use error handling pattern from xml_deserialization for json_de...2021-01-12T13:37:17+01:00Michael Thiesadapter.json: Use error handling pattern from xml_deserialization for json_deserializationIn the `aas.adapter.xml.xml_deserialization` we introduced an elegant error handling pattern to reduce code dupliction, consisting of the `_failsafe_construct()` and `_failsafe_construct_multiple()`, which wrap a constructor function to ...In the `aas.adapter.xml.xml_deserialization` we introduced an elegant error handling pattern to reduce code dupliction, consisting of the `_failsafe_construct()` and `_failsafe_construct_multiple()`, which wrap a constructor function to handle its raised Exceptions. We should apply the same pattern to the JSON deserialization.https://git.rwth-aachen.de/acplt/pyi40aas/-/issues/79Make DictObjectStore thread-safe (including object attribute access)2021-01-12T13:37:07+01:00Michael ThiesMake DictObjectStore thread-safe (including object attribute access)We need a concept for thread-safe object and attribute access to allow building multi-threaded applications. This is especially required to build a scalable web API using WSGI.We need a concept for thread-safe object and attribute access to allow building multi-threaded applications. This is especially required to build a scalable web API using WSGI.https://git.rwth-aachen.de/acplt/pyi40aas/-/issues/84aasx: Add more failsafe error handling2021-01-12T13:37:00+01:00Michael Thiesaasx: Add more failsafe error handlingCurrently, AASX reading raises an uncaught exception when an OPC part, referred to by a `File` object is not found or a duplicate `Identification` is found. We should handle those exceptions to make AASX reading more failsafe.Currently, AASX reading raises an uncaught exception when an OPC part, referred to by a `File` object is not found or a duplicate `Identification` is found. We should handle those exceptions to make AASX reading more failsafe.https://git.rwth-aachen.de/acplt/pyi40aas/-/issues/86sample data: Create an Asset and a ConceptDescription, referenced by multiple...2021-01-12T13:36:55+01:00Michael Thiessample data: Create an Asset and a ConceptDescription, referenced by multiple AAShttps://git.rwth-aachen.de/acplt/pyi40aas/-/issues/89backend: Add a local file-based backend2021-01-12T13:36:48+01:00Sebastian Heppners.heppner@iat.rwth-aachen.debackend: Add a local file-based backendAdd a local backend for storing identifiable objects locally as json or xml filesAdd a local backend for storing identifiable objects locally as json or xml fileshttps://git.rwth-aachen.de/acplt/pyi40aas/-/issues/91json/xml adapter: support serializing and deserializing stripped objects2021-01-12T13:36:29+01:00Leon Mauritz Möllerjson/xml adapter: support serializing and deserializing stripped objectsThe REST API requires serializing and deserializing stripped objects, without attributes for which a separate endpoint exists:
- `Qualifiable` (`SubmodelElement`, `DataElement`, `Submodel`) objects without the `qualifier` attribute
- `An...The REST API requires serializing and deserializing stripped objects, without attributes for which a separate endpoint exists:
- `Qualifiable` (`SubmodelElement`, `DataElement`, `Submodel`) objects without the `qualifier` attribute
- `AnnotatedRelationshipElement` without `annotation`
- `Entity` without `statements`
- `SubmodelElementCollection` without `value`
- `AssetAdministrationShell` without `views` and `submodel`
- `Submodel` without `submodel_element`
- **new in V3:** `HasExtension` (all `Referable`) objects without the `extension` attribute
Progress Tracker:
- [x] JSON Serialization
- [x] JSON Deserialization
- [ ] XML Serialization
- [x] XML Deserializationhttps://git.rwth-aachen.de/acplt/pyi40aas/-/issues/101model: Add string serialization/deserialization of Reference objects accordin...2021-01-12T13:36:19+01:00Michael Thiesmodel: Add string serialization/deserialization of Reference objects according to DotAAS sec. 5.2.1In Details of the Asset Administration Shell, section 5.2.1 (p. 95), a cannonical string representation of `Reference` objects is presented:
> In some mapping or serializations the Type “Reference” is converted into a single string. In ...In Details of the Asset Administration Shell, section 5.2.1 (p. 95), a cannonical string representation of `Reference` objects is presented:
> In some mapping or serializations the Type “Reference” is converted into a single string. In this case we recommend to use the following serilization:
>
> ```
> <Reference> ::= <Key>{,<Key>}*
> <Key> ::= (<KeyType>)(<Local>)[<KeyIdType>]<KeyValue>
> <KeyType> ::= value of AAS:Key/type
> <Local> ::= local | no-local
> <KeyIdType> ::= value of AAS:Key/.idType
> <KeyValue> ::= value of AAS:Key/value
> ```
>
> With `<Local> == local` if `AAS:Key/local = True` and `no-local` if `AAS:Key/local == False`.
>
> Examples:
> * `(ConceptDescription)(local)[IRDI]0173-1#02-BAA120#008`
> * `(GlobalReference)(no-local)[IRDI]0173-1#01-AFZ615#016`
> * `(Submodel)(local)[IRI]http://customer.com/demo/aas/1/1/1234859590,(Property)(local)[IdShort]Temperature`
(Plattform Industrie 4.0: "Details of the Asset Administration Shell – Part 1 - The exchange of information between partners in the value chain of Industrie 4.0 (Version 2.0.1)", CC BY-ND 4.0)
We could perfectly implement this representation as the `__str__` method of the `Reference` class and add a parser/constructor method like this:
```python3
@classmethod
def from_string(cls, value: str) -> "Reference":
# probably something with regex parsing here
```