Hi Gary and team, I wasn't on the tech team call, and I haven't been keeping up to date on the SPDX 3.0 modeling discussions, so please feel free to disregard the following if it isn't relevant...
>From the SPDX 2.2 perspective, if there were a change to the Files that a Package CONTAINS, then presumably the Package Verification Code would need to be changed accordingly. In that sense, a change to the CONTAINS for a Package's Files is more than just a Relationship change; rather, it changes the properties of the Package element itself. Given that, of the 3 choices given, I think that from the SPDX 2.2 perspective, it would be choice 3 -- both the Package's element and its Relationships would change. Perhaps not relevant if there isn't going to be a Package Verification Code (or equivalent) for Packages in 3.0, but just throwing it out there in case it's helpful for how to think about this. Steve On Wed, Jan 26, 2022 at 2:36 PM Gary O'Neall <[email protected]> wrote: > TL;DR: Please reply with any thoughts on the pros and cons to the 3 > different options for amending a contains relationship. Please try not to > duplicate – just reply with which scenario and which pro/con. If you need > clarification on the scenario or options, please start a separate thread. > > > > Here's the option description and pros and cons from the minutes: > > > > (1) Anytime there is a change in the contains relationship for a > package, one has to change the package element. > > Pro's: Concise for producer (initial production) without having > to amend it. Improve the quality (harder to miss updating relationships). > Graph navigation easier for un-amended. > > Con's: Less concise for amendments. Makes element reuse > difficult / less likely. Graph navigation is harder on amends, unless all > copied. > > (2) Anytime there is a change in the contains relationship, only the > relationships are changed. > > Pro's: More concise for amendments. Makes element reuse easier. > Graph navigation is easier on amends. > > Con's: : Less concise for producer (initial production) without > having to amend it. Lower quality – you must traverse and understand the > amends relationship to have a full understanding of what’s changed. Graph > navigation harder for un-amended. > > (3) Anytime there is a change in the contains relationship, the > element, the relationship or both can change. > > Pro's: > > Con's: > > > > Additional context (especially for those not on the tech call today): > > > > Last week, we discussed one of the Meta Issues – “Should we have > properties that duplicate relationships? And impact on round-tripping?” as > tracked in Issue #21 <https://github.com/spdx/spdx-3-model/issues/21>. > > > > Based on the email conversations, we started this week’s call with a > discussion if the package Element contains relationship could be changed. > We concluded that the Package Artifact contains relationships are fixed and > do not change. However, the Package Element and associated Contains > Relationships may change. This may be due to imperfect knowledge for the > initial creation of the SBOM, different use cases, better tools etc. > > > > Since the Contains metadata may change, how would an SBOM be amended? The > specific scenario is: > > > > 1. An SBOM is produced with a Package. The package contains files, > but the SBOM is not complete. > 2. An amended SBOM is produced with a better/corrected list of files > it contains. > > > > In creating the amended SBOM, there are 3 possible ways of representing > the changed SBOM: > > > > 1. Only the Package Element is amended: > 1. a new Package Element is created with an Amends relationship to > the previous incorrect Package element > 2. the new Package Element properties are updated as appropriate > 3. relationships to/from the Element are replaced if appropriate > 2. Only the relationships are amended or added: > 1. Any Contains relationships which are modified is amended by > creating a new Relationship with an Amends relationship to the previous > Relationship > 2. Any new Contains relationship is added > 3. Both – Both approaches to amending the SBOM is supported. A new > Package Element may be created, relationships may be modified, or both > > > > > > ------------------------------------------------- > > Gary O'Neall > > Principal Consultant > > Source Auditor Inc. > > Mobile: 408.805.0586 > > Email: [email protected] > > CONFIDENTIALITY NOTE: The information transmitted, including attachments, > is intended only for the person(s) or entity to which it is addressed and > may contain confidential and/or privileged material. Any review, > re-transmission, dissemination or other use of, or taking of any action in > reliance upon this information by persons or entities other than the > intended recipient is prohibited. If you received this in error, please > contact the sender and destroy any copies of this information. > > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#4344): https://lists.spdx.org/g/Spdx-tech/message/4344 Mute This Topic: https://lists.spdx.org/mt/88705040/21656 Group Owner: [email protected] Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
