Add new attributeType attribute to SpdxItem

[goneall]

Proposal (for 3.0):

Add new attribute attributeType that would be inherited by all SpdxItems (e.g. File, Package, Snippet). Cardinality [1] (required).

Justification: In many tooling (and some human) use cases, you are looking at the SpdxItem without the context of knowing whether the item is a File, Snippet, or Package. Having this as an attribute would make it easy to determine the type of artifact without having to backtrack through other document references.

Another justification is adding this would make the SPDX spec more compatible with other SBOM formats (e.g. https://github.com/cdfoundation/sig-security-sbom and https://github.com/CycloneDX)

Cons to adding this: This was discussed in the SPDX technical team on 7 Jan 2020 and concerns were raised that this information is not required, would break compatibility and make the spec more complex.

[goneall]

Note the related issue in SBOM to make the attribute field optional (cdfoundation/sig-security-sbom#18) - one of these approaches (but certainly not both) is needed to make the SBOM and SPDX compatible in 3.0.

[swinslow]

I'm neutral on whether to add this, no particular preference either way.

One question I'd have though is whether this piece of data (i.e., what concrete "class" this particular SpdxItem is) is also inherently determinable through other mandator fields for that item.

Put another way: If a Package is required to have a PackageName, and a File is required to have a FileName, and a Snippet is required to have a start / end byte field, then I don't really need a separate attributeType to tell me which one a particular SpdxItem is.

It still might be useful to have anyway, if e.g. it makes parsing easier. I guess I'm just asking whether it's truly necessary and how that balances against concerns re: expanded complexity of the spec and manifest file size.

[goneall]

The decision was made not to implement this in 3.0.

Closing issue.