Possible yes – but with limitations and challenges. The one challenge with having an Element outside of an SPDXDocument is validation. Once the canonicalization work is done, we may have a verification method that does not require a containing SPDXDocument. Another challenge is the location of the external SPDX element – without any locator information, finding the element would need to be done out of band.
Gary From: [email protected] <[email protected]> On Behalf Of David Kemp Sent: Wednesday, July 27, 2022 9:43 AM To: [email protected] Cc: William Bartholomew (CELA) <[email protected]>; SPDX-list <[email protected]> Subject: Re: [spdx-tech] 2022-07-26 Tech Meeting Model Proposal Dick, Is it possible to have an Element that is not part of an SPDXDocument and still be a valid SPDX document? An Element exists in the logical Element graph, and the Element graph can be updated without ever serializing any elements. So it is possible to have an Element that has never been serialized into any SPDX document. An SpdxDocument element is metadata about an SPDX document (transfer unit). A document can exist without ever creating an SpdxDocument element to describe it. So if I interpreted the question correctly, yes. If an SpdxDocument element is created to describe a document / transfer unit, it lists every Element that is serialized in that document. Regards, David On Wed, Jul 27, 2022 at 10:51 AM Dick Brooks <[email protected] <mailto:[email protected]> > wrote: David, Is it possible to have an Element that is not part of an SPDXDocument and still be a valid SPDX document? 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: David Kemp <[email protected] <mailto:[email protected]> > Sent: Wednesday, July 27, 2022 10:40 AM To: [email protected] <mailto:[email protected]> Cc: William Bartholomew (CELA) <[email protected] <mailto:[email protected]> >; SPDX-list <[email protected] <mailto:[email protected]> > Subject: Re: [spdx-tech] 2022-07-26 Tech Meeting Model Proposal Element is the type that all other element types inherit from. SpdxDocument inherits from Element, as do Bundle, BOM, and SBOM. SBOM is the root element of a logical collection of elements in a software bill of materials. The physical format of a software bill of materials could be anything, including a web page or PDF file. For machine readability and ease of human use, other physical formats are defined, including tag-value, spreadsheet, RDF, JSON, etc. The canonicalization group is working to define unambiguous algorithmic rules for converting between physical formats, so that a signature of an element or element collection can be computed once, and tools using any physical format can validate that signature. That unambiguous algorithmic conversion is enabled by a schema that applies to all data syntaxes. The root of that schema is a "transfer unit" or lower-case "spdx document". Upper-case SpdxDocument is the logical element type that is metadata about the spdx document file. Regards, David On Wed, Jul 27, 2022 at 8:20 AM Dick Brooks <[email protected] <mailto:[email protected]> > wrote: 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 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#4706): https://lists.spdx.org/g/Spdx-tech/message/4706 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]] -=-=-=-=-=-=-=-=-=-=-=-
