Workflow with Endpoints in Descriptors provided by Registry

[hofermo]

What is missing?

In the tutorial for the AAS API the interaction between the multiple Interfaces is specified:

Tutorial AAS Part 2 API
PDF Page 8

With the current spec it would be possible to have a Submodel Descriptor with an Endpoint that describes an AAS-Registry which does not make sense.

AAS Specification Part 2 API
PDF Page 82

...

How should it be fixed?

These questions arose when we tried to implement Registries in Mnestix Browser:

Is there somewhere specified what endpoints a AAS Descriptor and a Submodel Descriptor are allowed to have?
How should it be handled when e.g. an AAS Descriptor has an endpoint with a AAS Registry?
How should it be handled when e.g. an AAS Descriptor has an endpoint to a AAS as well as an endpoint to a AAS Repository?
Where is the source of truth when we have a SM Descriptor with an endpoint "Submodel" and an enpoint "Submodel-Repository"? -> There could be discrepancies when getting data from the Submodel Repo compared to the Submodel endpoint data. What should be higher prioritized?

A diagram or further explanation in the specification would be nice to clear up on how exactly the specified behaviour should look like.

[BirgitBoss]

Good point, we did not introduce constraints which values are allowed for Endpoint/interface in which context.
I would not be backward compatible to do so.

What we started to do is do give advice in the FAQ, e.g. here:
What are the right attribute values for 'Descriptor/endpoints?
So we could add some more best practice examples.

These are the described interactions being part of the specificaition themselves:
https://admin-shell-io.github.io/aas-specs-antora/IDTA-01002/v3.1/http-rest-api/interactions.html
From the description it might get clear what is expected although not explicitly specified.