Handling of optional sets if elements in serializations

[BirgitBoss]

*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]

See also #412

[BirgitBoss]

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.

[mristin]

(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.

[BirgitBoss]

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]

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