NOASSERTION should be a general concept and not element of the enum values

[maxhbr]

Currently the .png shows the ENUM values of DependencyScope:

noAssertion [default]
static
dynamic
tool
other

I think this should not include noAssertion and that instead there should be a general concept of optional values. And, if an optional value is not present, that can be serialized as NOASSERTION or null or ...

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

(It might also be an issue, that some programming languages have global namespaces for enum vaules and noAssertion is appearing in multiple ones)

[maxhbr]

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

[seabass-labrax]

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?

[davaya]

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

[maxhbr]

this is a duplicate of #76?

[kestewart]

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