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

Relax Constraint AASD-120 for SMT allow idShort in SML #432

Open
BirgitBoss opened this issue May 22, 2024 · 7 comments
Open

Relax Constraint AASD-120 for SMT allow idShort in SML #432

BirgitBoss opened this issue May 22, 2024 · 7 comments
Labels
accepted accepted in principle to be fixed requires workstream approval strategic decision in spec team needed specification impact on specification and thus on xml, json etc., label "aas-core" not set additinally
Milestone

Comments

@BirgitBoss
Copy link
Collaborator

BirgitBoss commented May 22, 2024

Is your feature request related to a problem? Please describe.
For Submodel Template creation it is helpful to have an idShort for the element type within the SML.
This is mainly the case for SML of SMC or SML because there are separate tables for SMC and SML. For properties it is more difficult.
See discussion in admin-shell-io/submodel-templates#65

Constraint AASd-120: idShort of submodel elements being a direct child of a SubmodelElementList shall not be specified.

could be relaxed to

Constraint AASd-120: idShort of submodel elements being a direct child of a SubmodelElementList shall not be specified within Submodels with kind=Instance.

Describe alternatives you've considered

  • do not relax
    -- instead create ConceptDescriptions with idShort of the corresponding elements

  • remove completely, i.e. also allow idShort in Submodels with kind=Instance for better readability

AASd-120 was a further restriction of
Constraint AASd-117: idShort of non-identifiable Referables not being a direct child of a SubmodelElementList shall be specified.

@BirgitBoss BirgitBoss added specification impact on specification and thus on xml, json etc., label "aas-core" not set additinally requires workstream approval strategic decision in spec team needed labels May 22, 2024
@BirgitBoss BirgitBoss changed the title Relax Constrain AASD-120 for SMT allow idShort in SML Relax Constraint AASD-120 for SMT allow idShort in SML May 22, 2024
@BirgitBoss BirgitBoss added this to the V3.1 milestone May 23, 2024
@BirgitBoss
Copy link
Collaborator Author

TF Part 1 2024-06-12 Decision Proposal:
remove AASd-120

@BirgitBoss BirgitBoss added ready for approval TF proposes how to resolve the issue. Needs final approval my Workstream accepted accepted in principle to be fixed requires workstream approval strategic decision in spec team needed and removed requires workstream approval strategic decision in spec team needed ready for approval TF proposes how to resolve the issue. Needs final approval my Workstream accepted accepted in principle to be fixed labels Jun 12, 2024
@BirgitBoss
Copy link
Collaborator Author

Accepted in principle by Workstream AAS Spec. 2024-06-13
Comments:

  • within a Submodel with kind=Instance idShorts need to be unique. For SMT there is only exactly one element allowed to be part of the SML.
  • However, in idShortPath idShort of SML elements shall not be used (because you cannot rely that the idShort exists)
  • In ValueOnly Format of API idShort will not be used (it is an JSON array)
  • even consider to make idShort mandatory for SML elements as well (then it could be used in idShortPath as well) However, this is not backward compatible
  • Part 2 affected as well, is there a need to add a corresponding comment in Part 2

TF AAS Part 1 will discuss this issue again and make a proposal

@BirgitBoss
Copy link
Collaborator Author

2024-07-24 TF Part 1
These constraints are relevant in this context:
Constraint AASd-117: idShort of non-identifiable Referables not being a direct child of a SubmodelElementList shall be specified.
Constraint AASd-120: idShort of submodel elements being a direct child of a SubmodelElementList shall not be specified.

If AASd-120 is removed then idShort is optional for elements within a SubmodelElementList (SML)

Discussion: shall we request this:
idShort of an element within a SML shall not be changed, the position wihtin a SML (the index) might be changed.
Decision: no, although typically an application would not do it

problem: if an element at position with index 3 is deleted, the position of element with index 4 changed to index 3. This would be the normal behavior of an array. However, if two users both want to remove element at index 3 it might happen if the execution requests are very close in time in the end both elements would be removed although this might not have been the intention.

https://admin-shell-io.github.io/aas-specs-antora/IDTA-01001/v3.1/mappings.html#_format_path_idshortpath_serialization_in_json
Discussion: should it be recommended to not use idShort in idShort-Path (since optional) or the opposite: use them if available (because of problem described above)
Decision: no additional note in this chapter

add note to AASd-117: In Future it might be required that idShort is also mandatory for elements within a SubmodelElementList.
does this imply that in future also in idShortPath only idShort shall be used? No

Decision Proposal:

@BirgitBoss BirgitBoss added the ready for approval TF proposes how to resolve the issue. Needs final approval my Workstream label Jul 24, 2024
@BirgitBoss
Copy link
Collaborator Author

BirgitBoss commented Jul 24, 2024

@sebbader may you please discuss this issue also in TF Part 2 API whether the impact on the API is accepted. Thank you.

In case idShortPath are returned: up to now index would be returned like in
"MySubmodelElementCollection.MySubSubmodelElementList2[0][0]"
In future theoretically also
"MySubmodelElementCollection.MySubSubmodelElementList2[myFirstElement][anotherFirstElement]"
would be possible

BirgitBoss added a commit that referenced this issue Jul 24, 2024
@BirgitBoss BirgitBoss added accepted accepted in principle to be fixed and removed ready for approval TF proposes how to resolve the issue. Needs final approval my Workstream labels Sep 12, 2024
@sebbader-sap
Copy link
Contributor

sebbader-sap commented Nov 14, 2024

WS AAS Specs (14.11.2024):
Also consider the effect for References that point to SubmodelElements inside SMLs:

{
    "type": "ModelReference",
    "keys": [
    {
       "type": "Submdel",
       "value":"http://example.org/my-submodel"
    },
   {
      "type": "SubmdelElementList",
      "value":"smlIdShort"
   },
   {
      "type": "Property",
     "value":"0"    // now a idShort could also appear here
   }
   ]
}

@sebbader-sap
Copy link
Contributor

Also appears in this notation:

(Submodel)https://example.com/aas/1/1/1234859590, (SubmodelElementList)Documents, (SubmodelElementCollection)0, (MultiLanguageProperty)Title

@mjacoby
Copy link

mjacoby commented Nov 15, 2024

Feedback from "Interoperability of Implementations"

Will affect implementations, but too few participants for significant results.
Trying again on 29.11.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
accepted accepted in principle to be fixed requires workstream approval strategic decision in spec team needed specification impact on specification and thus on xml, json etc., label "aas-core" not set additinally
Projects
None yet
Development

No branches or pull requests

3 participants