Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

extend allowed values for "interface" in Endpoints (SUBMODEL-VALUE etc.) #350

Open
BirgitBoss opened this issue Dec 4, 2024 · 1 comment
Labels
Milestone

Comments

@BirgitBoss
Copy link
Collaborator

BirgitBoss commented Dec 4, 2024

What is missing?

In https://admin-shell-io.github.io/aas-specs-antora/IDTA-01002/v3.1/specification/interfaces-payload.html#_endpoint we define the allowed "interface" values within the endpoint within an AAS or Submodel Registry.

We already discussed it whether to also support

  • "SUBMODEL-VALUE-3.0"
  • "SUBMODE-METADATA-3.0"
  • "SUBMODEL-PATH-3.0"
  • "SUBMODEL-3.0" would be for format "Normal"

etc. but decided that "SUBMODEL-3.0" is sufficient. This lead to the following requirements in Catena-X: add $value to endpoint

Now the problem is that sometimes the endpoint also contains parameters. These are not standardized in AAS but they are needed for a generic generation of the submodel data. If this is the case it is not possible to just add "$value" to the endpoint. Note: In the registry it is not required to have /submodel in the path, any endpoint returning the required payload it ok.

See our answer in
What are the right attribute values for 'Descriptor/endpoints'?
it does not cover how to deal with the different formats supported by AAS

@BirgitBoss BirgitBoss added the enhancement New feature or request label Dec 4, 2024
@BirgitBoss BirgitBoss changed the title Replace Title extend allowed values for "interface" in Endpoints (SUBMODEL-VALUE etc.) Dec 4, 2024
@BirgitBoss BirgitBoss added this to the 3.1 milestone Dec 4, 2024
@arnoweiss
Copy link

arnoweiss commented Dec 18, 2024

If the convention is to register the URL serving the full Submodel, what other serializations are covered is signaled by the Submodel servers' /description endpoint. I think the question is: what happens when a server ""decides"" to violate the ServiceSpecificationProfiles by leaving out the main endpoint? That's outside of the spec and just adding it here feels a little contradictory.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants