Open FrankSchnicke opened 1 year ago
To be clarified: Shall we put such topics into the specification or a related white paper/best practice document?
For me these are implementation related issues. It depends on the building blocks in the specification architecture how to do it. If you have two building blocks for AAS Registry and Submdoel Registry the implementation differs compared to an architecture with a single builing block for both. This is why we defined profiles: It is the task of the one implementing the profile to ensure consistency. See also the following note in the specification:
Note: the cardinality restriction for AssetAdministrationShellDescriptor/endpoint (optional: 0..*) allows a provider to skip the declaration of the location of an AssetAdministrationShell and directly point to the endpoints of the contained Submodels through the path AssetAdministrationShellDescriptor/submodelDescriptor-> SubmodelDescriptor/endpoint. A client, therefore, might decide to skip the lookup on the AssetAdministrationShell. Nevertheless, in case the information contained in the AssetAdministrationShellDescriptor deviates from the related AssetAdministrationShell, or attributes are missing, the AssetAdministrationShell is always the source of truth.
What?
The same issues described in https://github.com/admin-shell-io/aas-specs-api/issues/113 also pop up when using the superpaths for the AAS Registry:
/shell-descriptors/{aasIdentifier}/submodelDescriptors/*
In addition, it is not clear if the superpaths are expected to access the SubmodelDescriptors contained in the AASDescriptor or from a separate Submodel Registry due to the information redundancy (cf. https://github.com/admin-shell-io/aas-specs-api/issues/114).
How?
For proposals, see https://github.com/admin-shell-io/aas-specs-api/issues/113
In addition, clarify if the superpath accesses only the SubmodelDescriptors contained in the AASDescriptor or in a separate Submodel Registry.