Keep in mind that SPDX v2 is a schema - it defines the syntax of SPDX data, and it calls the top-level data type SPDXDocument. There is no such thing as graph elements and edges in SPDX v2.
In contrast, SPDX v3 is a logical graph. A collection element in that graph is semantically a "collection of elements", but data schemas are needed to define various syntaxes that have "collection-ish" semantics. There are many schema types that could represent collections, object and array are two basic syntaxes in JSON, and a schema specifies which to use and the details of how to use it. That's a lot of detail to answer the question, but the point is that in SPDX v2, "SPDXDocument" is a data type. In SPDX v3 "SpdxDocument" is an element which is metadata about a file containing data. SPDX v3 has elements that describe packages and files and documents (called Package and File and SpdxDocument respectively). It isn't too hard to keep in mind the difference between a package and the Package Element that describes it. But for some reason it is nearly impossible to keep in mind the difference between a document and a Document Element that describes it. So William came up with the brilliant idea of calling a file that contains data a "transfer unit". Normally it would be called "document", as in Word document or PDF document or XML document or JSON document, but due to that mental block, it is less ambiguous to call the file a "transfer unit". The Element type that describes a transfer unit file is called "SpdxDocument". And the schema type that defines the syntax of a transfer unit file is called TransferUnit. SPDX v2 document syntax: SPDXDocument SPDX v3 document syntax: TransferUnit SPDX v3 element metadata about a transfer unit: SpdxDocument. Clear as mud? In any case, the transfer unit file contains a specVersion property. And every logical Element contains a specVersion property. To repeat a previous email, a proposed syntax for the v3 transfer unit is: TransferUnit = Record 1 namespace IRI 2 namespaceMap NamespaceMap optional 3 createdBy ElementIRI [1..*] 4 created DateTime * 5 specVersion SemVer* // Default value for all elements serialized in this file 6 profiles ProfileIdentifier [1..*] 7 dataLicense LicenseId * 8 elementValues Element [1..*]* // All of the elements serialized in this file 9 spdxFileId ElementIRI optional 10 spdxFileRefs ElementIRI [0..*] The transfer unit data has one copy of specVersion that is the default value for all element values that don't override it. Logical elements always have full IRIs and explicit values for every property. Serializing elements into data files factors out the common data to save space and make elements easier to read without the extra boilerplate. Deserializing expands the common data back into element values. Regards, David On Wed, Jul 27, 2022 at 1:24 PM Dick Brooks < [email protected]> wrote: > Gary, > > > > I was specifically referring to SPDXVersion in section 6.1 in the V 2.2.2 > spec. > > > > Thanks, > > > > Dick Brooks > > > > *Active Member of the CISA Critical Manufacturing Sector, * > > *Sector Coordinating Council – A Public-Private Partnership* > > > > *Never trust software, always verify and report! > <https://reliableenergyanalytics.com/products>* ™ > > http://www.reliableenergyanalytics.com > > Email: [email protected] > > Tel: +1 978-696-1788 > > > > *From:* Gary O'Neall <[email protected]> > *Sent:* Wednesday, July 27, 2022 1:21 PM > *To:* [email protected]; 'David Kemp' <[email protected]> > *Cc:* 'William Bartholomew (CELA)' <[email protected]>; 'SPDX-list' < > [email protected]> > *Subject:* RE: [spdx-tech] 2022-07-26 Tech Meeting Model Proposal > > > > By SPDXVersion, do you mean the version of the SPDX specification? If so, > this is required in SPDX 2.X and I assume will be required in SPDX 3.0. If > you are referring to the package version, I didn’t see this in the current > SPDX 3 model – perhaps I’m missing something? I recall it being discussed > in some depth. It is an optional field in SPDX 2.X. > > > > Gary > > > > *From:* [email protected] <[email protected]> *On Behalf Of > *Dick Brooks > *Sent:* Wednesday, July 27, 2022 9:55 AM > *To:* 'Gary O'Neall' <[email protected]>; 'David Kemp' < > [email protected]> > *Cc:* 'William Bartholomew (CELA)' <[email protected]>; 'SPDX-list' < > [email protected]> > *Subject:* Re: [spdx-tech] 2022-07-26 Tech Meeting Model Proposal > > > > Gary, > > > > One SPDX Element that is vitally important to our processing of SPDX SBOM’s > is the presence of an SPDXVersion element. > > > > Under the V 3.0 model, is it possible to have a valid SPDX Document, > without an SPDXVersion element? > > > > Thanks, > > > > Dick Brooks > > > > *Active Member of the CISA Critical Manufacturing Sector, * > > *Sector Coordinating Council – A Public-Private Partnership* > > > > *Never trust software, always verify and report! > <https://reliableenergyanalytics.com/products>* ™ > > http://www.reliableenergyanalytics.com > > Email: [email protected] > > Tel: +1 978-696-1788 > > > > *From:* Gary O'Neall <[email protected]> > *Sent:* Wednesday, July 27, 2022 12:48 PM > *To:* 'David Kemp' <[email protected]>; [email protected] > *Cc:* 'William Bartholomew (CELA)' <[email protected]>; 'SPDX-list' < > [email protected]> > *Subject:* RE: [spdx-tech] 2022-07-26 Tech Meeting Model Proposal > > > > 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]> 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* > > > > *Never trust software, always verify and report! > <https://reliableenergyanalytics.com/products>* ™ > > http://www.reliableenergyanalytics.com > > Email: [email protected] > > Tel: +1 978-696-1788 > > > > *From:* David Kemp <[email protected]> > *Sent:* Wednesday, July 27, 2022 10:40 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 > > > > 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]> 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 (#4711): https://lists.spdx.org/g/Spdx-tech/message/4711 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]] -=-=-=-=-=-=-=-=-=-=-=-
