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.

Sign up for GitHub

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

Jump to bottom

Handling of optional sets if elements in serializations #418

Closed
BirgitBoss opened this issue Apr 20, 2024 · 6 comments
Closed

Handling of optional sets if elements in serializations #418

BirgitBoss opened this issue Apr 20, 2024 · 6 comments
Labels
accepted accepted in principle to be fixed specification impact on specification and thus on xml, json etc., label "aas-core" not set additinally
Milestone
V3.0.1

Comments

@BirgitBoss
Copy link
Collaborator

*Is your feature request related to a problem? Please describe.

see admin-shell-io/aas-test-engines#13 (comment) @mjacoby

„the JSON schema says an Environment must have at least 1 conceptDescription. However, the AAS specification (Section 5.3.9, page 81) says it can have zero or more elements.

At first glance, this seems like a bug. However, I could find the following sentence in a README on Github

Optional attributes, i.e., the attributes with the cardinality 0..1, are modeled as [non-required properties].
This indicates, that in JSON the property conceptDescriptions should not be present at all if empty and if present must be non-empty. This would mean that the provided JSON is actually invalid.

However, I would argue that this sentence is not part of the specification itself and therefore not normative.

The correct way would be either to put this sentence in the specification or changes the JSON schema to reflect what is written in the spec, i.e. allow the property to be empty.“
@BirgitBoss BirgitBoss added this to the V3.1 milestone Apr 20, 2024
@BirgitBoss BirgitBoss mentioned this issue Apr 20, 2024
Closed
@BirgitBoss BirgitBoss added 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 labels Apr 20, 2024
@BirgitBoss
Copy link
Collaborator Author

See also #412

@BirgitBoss
Copy link
Collaborator Author

BirgitBoss commented Apr 20, 2024 •
edited
Loading

In Annex D of IDTA-3-0, Page 134, it is stated:

“0..1" means optional. "0.." or "0..3" etc. means that the list may be either not available (null object) or empty.

the Schemas are more strict.

@juileetikekar juileetikekar mentioned this issue May 8, 2024
Closed
@mristin
Copy link
Collaborator

mristin commented May 8, 2024

(Copied from eclipse-aaspe/package-explorer#195, relevant here as well)

Just for reference. Here's the excerpt from https://github.com/admin-shell-io/aas-specs/tree/1bf6df90bc3f56df4d5619b6ee0ce5382bde0168/schemas/json#uml-properties-to-json-properties (current latest version):

Aggregations, i.e., the properties with the cardinality 0.., 1.. etc., are modeled as JSON arrays.

We explicitly forbid empty JSON arrays to avoid confusion about properties which have cardinality 0..*. Namely, an empty array is semantically equal to an omitted attribute (according to the meta-model). Thus, the JSON property representing an aggregation attribute must be omitted if the aggregation is empty.

@juileetikekar juileetikekar mentioned this issue May 13, 2024
Closed
@BirgitBoss
Copy link
Collaborator Author

BirgitBoss commented May 15, 2024 •
edited
Loading

2024-05-15 TF AAS Part 1
yes, this is the expected behavior, no bug

==> Specification Annex will be corrected:
from
" "0.." or "0..3" etc. means that the list may be either not available (null object) or empty." is not correct
to
"0.." or "0..3" etc. means that the list may be either not available (optional) or the list is not empty.

@BirgitBoss BirgitBoss added the ready for approval TF proposes how to resolve the issue. Needs final approval my Workstream label May 15, 2024
@BirgitBoss BirgitBoss removed the requires workstream approval strategic decision in spec team needed label May 29, 2024
BirgitBoss added a commit that referenced this issue Jun 3, 2024
@BirgitBoss
V3.0.1 changes
f8700d9 
#418 CHANGE (Editorial, the schemas implemented it like this)
Annex UML Tables: "0..*" or "0..3" etc.
means that the list may be either not available (optional) or the list is not empty.
@BirgitBoss BirgitBoss modified the milestones: V3.1, V3.0.1 Jun 3, 2024
@BirgitBoss
Copy link
Collaborator Author

see also #411: similar to Part 2 we may combine optional and empty but this then needs to be explicitly specified

@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 Jun 13, 2024
BirgitBoss added a commit that referenced this issue Jun 14, 2024
@BirgitBoss
Correct figures for data specifications (#437)
49072d9 
* correct figure (no idShort for DataSpecification)

* no message

* V3.0.1 changes

* V3.0.1 changes
#418 CHANGE (Editorial, the schemas implemented it like this)
Annex UML Tables: "0..*" or "0..3" etc.
means that the list may be either not available (optional) or the list is not empty.
BirgitBoss added a commit that referenced this issue Jun 20, 2024
@zrgt @BirgitBoss
Fix editorial changes (#441)
e3ce9b6 
* update to V3.0.1( DataTypeDefXsd, PathType) (#430)

* V3.0.1:
fix figure (xs:float not at correct place)
+ update Changelog accordingly

* Now PathType change already part of V3.0.1
ChangeLog changed accordingly

* add subchapter for better structuring

* Incorporate changes from V3.0.1 (#436)

* V3.0.1:
fix figure (xs:float not at correct place)
+ update Changelog accordingly

* Now PathType change already part of V3.0.1
ChangeLog changed accordingly

* add subchapter for better structuring

* • (Editorial) correct information in Changes V3.0 vs. V3.0RC02 w.r.t. VersionType and RevisionType

* #438 correct Figure AssetInformation
w.r.t. Resource/path and Resource/value cardinality
+ update changeLog

* Correct figures for data specifications (#437)

* correct figure (no idShort for DataSpecification)

* no message

* V3.0.1 changes

* V3.0.1 changes
#418 CHANGE (Editorial, the schemas implemented it like this)
Annex UML Tables: "0..*" or "0..3" etc.
means that the list may be either not available (optional) or the list is not empty.

* Remove remaining "IDTA-01xxx_"-Prefixes in refs

* Remove Imprint.adoc, as not used

* Remove unused duplicated file

* Rename adoc files acc. to other spec parts

- Removed uppercases in file names acc. to Antora docs: "Although not required, we strongly recommend that you always use lowercase for filenames. Some filesystems are case sensitive, while others are not. By always using lowercase, you avoid any problems that occur if the filesystem, webserver, or transfer tool does not preserve the casing." (https://docs.antora.org/antora/latest/organize-content-files/#storing-your-content-source-files)

---------

Co-authored-by: Birgit Boss <[email protected]>
@BirgitBoss
Copy link
Collaborator Author

solved in IDTA-01001-3-0-1: https://industrialdigitaltwin.org/wp-content/uploads/2024/06/IDTA-01001-3-0-1_SpecificationAssetAdministrationShell_Part1_Metamodel.pdf

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
accepted accepted in principle to be fixed specification impact on specification and thus on xml, json etc., label "aas-core" not set additinally
Projects
None yet
Milestone
V3.0.1
Development

No branches or pull requests
2 participants
@mristin @BirgitBoss