In my opinion every artifact that follows the SPDX V n.n spec uses the SPDXDocument base type that all other SPDX artifacts inherit from. Looking at the current model one could infer that elements are not part of an SPDXDocument.
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: <mailto:[email protected]> [email protected] Tel: +1 978-696-1788 From: [email protected] <[email protected]> On Behalf Of David Kemp Sent: Tuesday, July 26, 2022 8:47 PM To: William Bartholomew (CELA) <[email protected]> Cc: [email protected] Subject: Re: [spdx-tech] 2022-07-26 Tech Meeting Model Proposal SpdxDocument has the downloadUrl property that is not included in Bundle, which is why they are not the same. They are also semantically different. The collection of elements that make up a BOM/SBOM is serialization-independent and always the same for a given BOM. The collection of elements that make up an SpdxDocument is arbitrary. Bundle and SpdxDocument are both Collections, but * Bundle is a logical collection of the elements in a BOM or the logical collection of elements that have some purpose/context (e.g., all Identities starting with a-c). * SpdxDocument describes a physical collection and lists the elements in a transfer unit file A Bundle can be split across many SpdxDocuments, or many Bundles can be merged into one SpdxDocument. Or an SpdxDocument can have elements unrelated to Bundles, such as every element created in the past 5 minutes, generated by a cron job and used to keep Element Stores in sync. If you make SpdxDocument inherit from Bundle, you destroy the semantic difference between logical and physical collections. In order to unblock the discussion, you should: * show SpdxDocument inherit from Collection * show the physical data structure described by SpdxDocument in the Data Structure side of the diagram - it is a single root object containing properties, including transfer unit creation date and actor, other property defaults, an array of [1..*] elementValues and an array of [0..*] spdxDocumentReferences. Regards, David On Tue, Jul 26, 2022 at 3:04 PM William Bartholomew (CELA) via lists.spdx.org <http://lists.spdx.org> <[email protected] <mailto:[email protected]> > wrote: This PR has the model I proposed at the end of today’s meeting: https://github.com/spdx/spdx-3-model/pull/25 >From the PR description: This is the model I proposed at the end of the meeting. Notable changes: * Added the missing inherits from Collection to Element. * Renamed Document to SpdxDocument. * Added Bundle and moved BOM to inherit from Bundle to remove the implication that BOM's need to be a serialization root. * Moved SpdxDocument to inherit from Bundle since they are a special type of bundle. There is an open question on whether the distinction between SpdxDocument and Bundle is necessary, but this proposal doesn't force you to use SpdxDocument while providing a clear migration path from SPDX 2.x. If during the formal definition of the classes it becomes clear we don't need both they can be collapsed together, but for now this would unblock us. Regards, William Bartholomew (he/him) – Let’s chat <https://outlook.office.com/bookwithme/user/[email protected]/meetingtype/SVRwCe7HMUGxuT6WGxi68g2?anonymous&ep=mlink> Principal Security Strategist Global Cybersecurity Policy – Microsoft My working day may not be your working day. Please don’t feel obliged to reply to this e-mail outside of your normal working hours. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#4702): https://lists.spdx.org/g/Spdx-tech/message/4702 Mute This Topic: https://lists.spdx.org/mt/92634687/21656 Group Owner: [email protected] Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
