-
Notifications
You must be signed in to change notification settings - Fork 134
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Should packagePurpose have cardinality 0..1? #720
Comments
I agree with @rjb4standards issue - I would vote to change the cardinality to |
@nishakm @rnjudge @tsteenbe @kestewart - any input on this issue? |
+1 from me as well. |
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. |
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. |
+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.
|
@goneall, I'm one of the proponents you mention 😃 I feel strongly that this should be PS. This would apply to both 2.x and 3.x. |
@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. |
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:
There are probably more solutions out there. I'm thinking the fastest path to release 2.3 is option 4. |
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. |
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. |
Excellent point - I'll retract that incorrect statement |
Fixes #720 Signed-off-by: Gary O'Neall <gary@sourceauditor.com>
With a couple votes for option 4, I created PR #721 with proposed changes. |
@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. |
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: ***@***.***>
|
Fixes #720 Signed-off-by: Gary O'Neall <gary@sourceauditor.com>
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: ***@***.***>
|
It was brought to the attention of the group in the most recent SPDX DocFest that the Primary Package Purpose cardinality was incorrectly listed in the spec as 0..* despite the decision[1] that it should be 0..1. The cardinality was correct in the JSON schema and OWL ontology, however, so the consensus was to update the 2.3 specification text with a note noting the update. [1] spdx#720 Signed-off-by: Rose Judge <rjudge@vmware.com>
It was brought to the attention of the group in the most recent SPDX DocFest that the Primary Package Purpose cardinality was incorrectly listed in the spec as 0..* despite the decision[1] that it should be 0..1. The cardinality was correct in the JSON schema and OWL ontology, however, so the consensus was to update the 2.3 specification text with a note noting the update. [1] spdx#720 Signed-off-by: Rose Judge <rjudge@vmware.com>
It was brought to the attention of the group in the most recent SPDX DocFest that the Primary Package Purpose cardinality was incorrectly listed in the spec as 0..* despite the decision[1] that it should be 0..1. The cardinality was correct in the JSON schema and OWL ontology, however, so the consensus was to update the 2.3 specification text with a note noting the update. [1] #720 Signed-off-by: Rose Judge <rjudge@vmware.com>
Package Purpose currently has a cardinality of
0..*
allowing more than one purpose.@rjb4standards raised a good issue in the schema pull request:
Should we change the cardinality to
0..1
to resolve this issue?The text was updated successfully, but these errors were encountered: