`NOASSERTION` should be a general concept and not element of the enum values about spdx-3-model HOT 5 CLOSED

optional values (or NOASSERTION) is also something that is necessary for non enum values.

from spdx-3-model.

I completely agree - 'no assertion' is a concept, one which is permitted for some fields (the value is said to be optional) and prohibited for other fields (the value is said to be required).

It makes sense for 'no assertion' to be expressed in a serialisation format or programming language's 'native' way, if available. Thus, in a Clojure implementation I would use nil for 'no assertion', and for the JSON serialisation format, we (SPDX) might decide that, say, it's the omission of the field's key-value pair that signifies 'no assertion'.

If an Element declares that it conforms to a specific SPDX profile, that may make some fields required where they would otherwise be optional.

As a clarification, when you say:

Further, the default value and cardinallity of an enum should be decided by the user and not by the enum.

...I presume you are referring to SPDX Element types that have an Enum field, not the 'end user' of SPDX data?

from spdx-3-model.

+1

It should be noted that UNKNOWN is distinct from NOASSERTION -- it is an explicit statement rather than the lack of a statement, so UNKNOWN Is a legitimate enumerated item.

For fields that are optional in some contexts and required in others, both application behavior and serialization must be carefully considered.

• Logical: does an application variable with field=nil compare as equal to the same object with field absent? It should, but in practice programming languages may not make it so.
• Physical: a serialized value with field=nil definitely hashes to a different value than with the field absent.

from spdx-3-model.

this is a duplicate of #76?

from spdx-3-model.

Close this issue as it's being tracked in #76

from spdx-3-model.