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

[BirgitBoss]

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]

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 admin-shell-io/aas-specs#432 (comment)) which to older clients will not be a valid idShortPath.

[sebbader-sap]

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

[BirgitBoss]

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]

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]

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.

[mjacoby]

Feedback from implementers via TF Interoperability of Implementations:

• the motivating use case (Documentation of SML with SMC as child in Submodel Template (SMT) specifications submodel-templates#65) seem not really strong and should rather be solved by changing the table to not misuse idShort of type declaration but introduce a type field or similar
• implementation would be possible but would require some efforts and maybe even pose a threat/challenge for scalability
• also sentiment ist that accessing elements in a list/array by something else than the index is very unusual for an API/programming language

The conclusion is that the TF recommends to not go forward with this changes until there is a solid use case/requirement.