[GetAllAssetAdministrationShellsByAssetId] Intended Use Case?

[FrankSchnicke]

What?

GetAllAssetAdministrationShellsByAssetId (i.e., /shells?assetIds=XYZ) is providing functionality similar to the AAS Discovery (GetAllAssetAdministrationShellIdsByAssetLink), however, limited to a single AAS Repository.

In a fully distributed deployment it may not behave as expected because the AAS it is looking for may be in a different repository. As a result, using this endpoint in an application may become an obstacle to later changes in the architecture when an AAS is redeployed (similar to the superpaths discussed in other tickets). As a result, from my understanding, this endpoint ties the application using it to the architectural decision to use a centralised approach, and I would not use it to avoid changes in applications due to possible future redeployments.

Is there another intended use for this endpoint that I'm not aware of were it would provide value?

• [x] I have signed the required Developer Certificate of Origin (DCO) already.

[sebbader-sap]

Hello Frank,

this endpoint ties the application using it to the architectural decision to use a centralised approach

Why would that be the case? Given that the result of this call would be an empty array, the only conclusion the client can make is that "This repository does not contain the AAS for my Asset" but not "No AAS exists for my Asset".

It's the general topic of open world vs. closed world views, isn't it?

[sebbader-sap]

We discussed this topic in the meeting today. While we all share the general view that an empty response from any AAS service must not be interpreted in a way that a respective AAS, Submodel, Asset etc. does not exist, we agree that this has not yet been clearly communicated.

Therefore, the proposal is to add a statement explaining the topic into the AAS API (Part 2) document.

[sebbader]

The AAS Specification Workstream supports the proposal, therefore, an explaining statement will be added in the next publication.