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

Cardinality > 1, distinguish between Map / Array #411

Open
alexgordtop opened this issue Apr 16, 2024 · 2 comments
Open

Cardinality > 1, distinguish between Map / Array #411

alexgordtop opened this issue Apr 16, 2024 · 2 comments
Labels
documentation Improvements or additions to documentation requires workstream approval strategic decision in spec team needed
Milestone

Comments

@alexgordtop
Copy link

alexgordtop commented Apr 16, 2024

The model should distinguish for attributes with cardinality > 1, it it is a kind of array/list or a kind of object/map.

This is relevant for Value-Only serialization only. For Normal it is always an array.

@BirgitBoss BirgitBoss added this to the V3.1 milestone Apr 16, 2024
@BirgitBoss BirgitBoss added requires workstream approval strategic decision in spec team needed documentation Improvements or additions to documentation labels May 15, 2024
@BirgitBoss
Copy link
Collaborator

In Part 2 for interfaces

image

Mandatory and Cardinality are distinguished. So there might be an optional element but the cardinality is 1. No Null object allowed in this case.

Similar we can add an additional column to the class definitions. For all cases with 0..1, 0..* etc. we need to define whether empty lists or NULL objects are allowed. To be backward compatible to the schema implementations we would have in the moment:

  • mandatory: false
  • Cardinality: 1 or 1..*
    etc.

@s-heppner
Copy link
Collaborator

If I get this correctly, you want to specify in the model how a given attribute with cardinality > 1 should be implemented? (As a list or an array?)

That is nothing a technology-neutral model should specify in my opinion. What if there was an AAS implementation in a programming language that handles multivalued attributes differently and does not offer one or the other?
If you want to specify this, it should be in the return value of the API call, imo.

Please correct me, if I didn't get the problem right.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation requires workstream approval strategic decision in spec team needed
Projects
None yet
Development

No branches or pull requests

3 participants