Should packagePurpose have cardinality 0..1?

[goneall]

Package Purpose currently has a cardinality of 0..* allowing more than one purpose.

@rjb4standards raised a good issue in the schema pull request:

I'm concerned that making PackagePurpose an array will impact fidelity when translating to other formats, plus it raises ambiguity as to the "primary purpose" of a package.

Should we change the cardinality to 0..1 to resolve this issue?

[goneall]

I agree with @rjb4standards issue - I would vote to change the cardinality to 0..1

[goneall]

@nishakm @rnjudge @tsteenbe @kestewart - any input on this issue?

[rnjudge]

I agree with @rjb4standards issue - I would vote to change the cardinality to 0..1

+1 from me as well. 0..1 makes sense.

[davaya]

This was covered in the v3 discussions, and I believe the consensus was that a package could have multiple SoftwarePurposes (e.g., [APPLICATION, SOURCE]). Since Package Purpose didn't exist in v2.2.2 and was added in 2.3, one might conclude that it was a backport of something deemed useful from v.3.

If the decision is to allow only a single purpose in 2.3, then the same rationale should apply and v3.0 should also allow only a single purpose. I take no position on which to choose, only that they be consistent.

[goneall]

If the decision is to allow only a single purpose in 2.3, then the same rationale should apply and v3.0 should also allow only a single purpose. I take no position on which to choose, only that they be consistent.

Agree - my vote would be to change this for both 2.3 and 3.0

Now bringing @iamwillbar into the conversation. William - do you recall the proponents of allowing more than one purpose? If it was theoretical, we have a practical reason to keep it at 1. If there was a use case which required multiple, we should probably discuss before making a decision.

[rjb4standards]

+1 to Garys suggestion

…

Sent from my iPhone

On Jun 15, 2022, at 7:04 PM, goneall ***@***.***> wrote:  If the decision is to allow only a single purpose in 2.3, then the same rationale should apply and v3.0 should also allow only a single purpose. I take no position on which to choose, only that they be consistent. Agree - my vote would be to change this for both 2.3 and 3.0 Now bringing @iamwillbar into the conversation. William - do you recall the proponents of allowing more than one purpose? If it was theoretical, we have a practical reason to keep it at 1. If there was a use case which required multiple, we should probably discuss before making a decision. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.

[seabass-labrax]

@goneall, I'm one of the proponents you mention 😃

I feel strongly that this should be 0..*, which is what we came to in previous discussions (see my reply to Nisha on the original pull request for context). This is because some of the package purpose options overlap, limiting future use of a SBOM in which a more general statement is made.

PS. This would apply to both 2.x and 3.x.

[rjb4standards]

@seabass-labrax was there any discussion regarding how to identify the "primary purpose" when the set contains > 1 purpose? As an implementer I want to be able to identify the primary purpose, so that I can decide which introspection logic to apply to the object. For example, our SW processes INSTALL packages very differently from "FILE" packages.
Please be aware that my vision is tightly constrained to the use of SBOM for consumer side SW risk assessments following NIST C-SCRM and EO 14028 guidance, so I don't always see the big picture on how SBOM is used.

[goneall]

I have the same issue @rjb4standards describes above when converting between SBOM formats.

Sounds like something that needs further thought and discussion.

@seabass-labrax - Do you have a concrete planned usage for more than one purpose or is this more a case where we want to design for the future possibilities?

Here's the options I can think of:

1. Leave the cardinality in 2.3 at 0..*
2. Change the cardinality to 0..1 in both 2.3 and 3.0
3. Change the cardinality in 2.3 to 0..1 to solve the issues described above and leave open the possibility to change to 0..* in 3.0.
   Since a cardinality of 0..* is backwards compatible with a cardinality of 0..1, we could make this 0..1 in version 2.3 and change to 1..* in 3.0.
4. Change the name of the 2.3 property to 'primaryPackagePurpose' and set the cardinality to 0..1. We could then introduce a more general package purposes if there are use cases that need this. This would be in addition to the primaryPackagePurpose.

There are probably more solutions out there.

I'm thinking the fastest path to release 2.3 is option 4.

[rjb4standards]

I support Gary's option 4 proposal. This decision impacts developers ability to code parsing logic for V 2.3. Please treat this matter with some urgency. Thank you.

[davaya]

Cardinality of 0..* is not strictly compatible with cardinality of 0..1 unless you mandate that for properties with cardinality 0..*, an instance of one must be serialized differently from an instance of two or more: a string vs. a list containing one string. That would be possible, but quite unusual since it requires runtime determination of data types.

So option 4 is preferable to option 3.

The problem with the SoftwarePurpose list is that it is multi-dimensional; some purposes are mutually-exclusive while others are characteristics that can be applied to other purposes. I'd vote for option 4, and also limit the enumerated primary purposes to be mutually exclusive and collectively exhaustive, making it easier for different tools to arrive at the same conclusion.

[goneall]

Cardinality of 0..* is not strictly compatible with cardinality of 0..1 unless you mandate that for properties with cardinality 0..*, an instance of one must be serialized differently from an instance of two or more: a string vs. a list containing one string. That would be possible, but quite unusual since it requires runtime determination of data types.

Excellent point - I'll retract that incorrect statement

[goneall]

With a couple votes for option 4, I created PR #721 with proposed changes.

[goneall]

@seabass-labrax - Just checking to make sure you're OK with the proposed solution of 2 properties - one with a cardinality of 0..1 and one with a cardinality of 0..* - that way we can achieve both use cases. We'll introduce the one with cardinality 0..1 in 2.3 since it is key to solving some of the security related use cases.

[rjb4standards]

Gary, REA is prepared to implement the PrimaryPackagePurpose with a cardinality of 0..1 in SPDX V 2.3 as a sub-element within a Package description, as shown in the example below in Tag Value format: PrimaryPackagePurpose: INSTALL Thanks, Dick Brooks Active Member of the CISA Critical Manufacturing Sector, Sector Coordinating Council – A Public-Private Partnership <https://reliableenergyanalytics.com/products> Never trust software, always verify and report! ™ <http://www.reliableenergyanalytics.com/> http://www.reliableenergyanalytics.com Email: ***@***.***> ***@***.*** Tel: +1 978-696-1788 From: goneall ***@***.***> Sent: Tuesday, June 21, 2022 10:50 AM To: spdx/spdx-spec ***@***.***> Cc: Dick Brooks ***@***.***>; Mention ***@***.***> Subject: Re: [spdx/spdx-spec] Should packagePurpose have cardinality 0..1? (Issue #720) @seabass-labrax <https://github.com/seabass-labrax> - Just checking to make sure you're OK with the proposed solution of 2 properties - one with a cardinality of 0..1 and one with a cardinality of 0..* - that way we can achieve both use cases. We'll introduce the one with cardinality 0..1 in 2.3 since it is key to solving some of the security related use cases. — Reply to this email directly, view it on GitHub <#720 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABFI3NB7YGKWFZRPWQF6DLLVQHJATANCNFSM5Y3Z276A> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[rjb4standards]

David, An optional singleton (0..1) is preferred by REA for SPDX V 2.3, following Gary’s proposal (4). Thanks, Dick Brooks Active Member of the CISA Critical Manufacturing Sector, Sector Coordinating Council – A Public-Private Partnership <https://reliableenergyanalytics.com/products> Never trust software, always verify and report! ™ <http://www.reliableenergyanalytics.com/> http://www.reliableenergyanalytics.com Email: ***@***.***> ***@***.*** Tel: +1 978-696-1788 From: David Kemp ***@***.***> Sent: Thursday, June 16, 2022 2:08 PM To: spdx/spdx-spec ***@***.***> Cc: Dick Brooks ***@***.***>; Mention ***@***.***> Subject: Re: [spdx/spdx-spec] Should packagePurpose have cardinality 0..1? (Issue #720) Cardinality of 0..* is not strictly compatible with cardinality of 0..1 unless you mandate that for properties with cardinality 0..*, an instance of one must be serialized differently from an instance of two or more: a string vs. a list containing one string. That would be possible, but quite unusual since it requires runtime determination of data types. — Reply to this email directly, view it on GitHub <#720 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABFI3NFU53W236Y5T5J7JYTVPNUQFANCNFSM5Y3Z276A> . You are receiving this because you were mentioned.Message ID: ***@***.***>