search

admin-shell-io / aas-specs-api

Repository of the Asset Administration Shell Specification DTA-01002 API
https://admin-shell-io.github.io/aas-specs-antora/index/home/index.html
Creative Commons Attribution 4.0 International
12 stars 5 forks source link

idShort for Elements within SML: does this have impact on API? #334

Open BirgitBoss opened 1 month ago

BirgitBoss commented 1 month ago

What is missing?

Describe the problem in short sentences, add a minimal example if possible
see aas-spec #432

In V3.1 Metamodel is planned to support idShort also for SubmodelElementList. Does this have any impact on API?

mjacoby commented 1 month ago

I think this would be a breaking change to the API because a server could now return MySubmodelElementCollection.MySubSubmodelElementList2[myFirstElement][anotherFirstElement] instead MySubmodelElementCollection.MySubSubmodelElementList2[0][0] for the idShortPath serialization (see https://github.com/admin-shell-io/aas-specs/issues/432#issuecomment-2248224629) which to older clients will not be a valid idShortPath.

sebbader-sap commented 1 month ago

Remark: Most likely the final idShortPath would look like this: MySubmodelElementCollection.MySubSubmodelElementList2.myFirstElement.anotherFirstElement

BirgitBoss commented 3 weeks ago

The API could define a parameter for path-with-list-number (default like today) and path-with-list-idshort: numbers re always available, idShort is optional. In case no idShort would be defined the index-number would be returned.

I.e. add new value to Content Parameters in [Clause SerializationModifier](https://admin-shell-io.github.io/aas-specs-antora/IDTA-01002/v3.1/specification/interfaces-operation-parameters.html#SerializationModifier*

sebbader-sap commented 1 week ago

Maybe we don't need a new ContentParameter. A V3.1 server may treat the following IdShortPaths equivalently: MySubmodelElementCollection.MySubSubmodelElementList2.myFirstElement.anotherFirstElement MySubmodelElementCollection.MySubSubmodelElementList2[0].anotherFirstElement

While a V3.0 server may return a the SubmodelElement for the first variant but return a 404 for the latter. But syntactically / functionally all will work.

mjacoby commented 1 week ago

If we treat both idShortPaths equivalently, what about the results returned by a server for requests with content=path in regards to backwards compatibility?

If a server is free to return any format, this would be a breaking change as v.30 clients could not handle paths like MySubmodelElementCollection.MySubSubmodelElementList2.myFirstElement.anotherFirstElement.

The only way I see to keep backwards compatibility would be to force v3.1 servers to always return index-based idShortPaths while accepting both index-based and idShort-based idShortPaths.