William has been gathering punch list questions during the meetings, and we've tried to avoid taking up meeting time on engineering the solutions. This is my perspective on the subject question.
* A document is a sequence of bytes. This is normally a file, but as Nisha pointed out it could also be the response to an SQL query, or to any API call. A File Element has an artifactUri, a media type, and a filePurpose - if this is sufficient to describe a byte sequence returned from an API at the artifactUri address, great. If not, the logical model could define a new Artifact sub-type for byte sequences returned from API calls. * An Artifact element (File or a new "ByteSequence" type) describes a sequence of bytes. * A sequence of bytes can be signed or hashed. (The details of what to hash, i.e., how to canonicalize a byte sequence, can be worked out later.) If we have a File Element referring to a JPG file, the bytes of the File Element are not included in the bytes of the JPG file. If we have a File Element referring to an SPDXv2 file, the bytes of the File Element are not included in the SPDXv2 file. So if we have a File Element referring to an SPDXv3 file, the bytes of the FileElement are not required to be included in the SPDXv3 file. The problem with answering the question is: SPDXv2.2 Document contains: * Document Creation Information * Package Information * ... * Annotation Information But the SPDXv3 logical model currently says: SPDXv3 Document contains: * Document Element (NOT Document Creation Information) * SBOM Element(s) * Package Element(s) * ... * Annotation Element(s) In v2 Document means "The SBOM" and document means "the bytes of the serialized SBOM". There is no "SBOM Information" analogous to Package/File/Annotation Information in v2. In v3 SBOM means "The SBOM" and document means "the bytes of the serialized SBOM". The Document Element in v3 is the Artifact referring to "the bytes of the serialized SBOM". (In v3 any Element can be serialized; I'm referring to implementing the v2 use case of serializing an SBOM in v3.) The SBOM Element (like all Elements) has its own creation information, so when it is serialized the document creation information can be (but is not constrained to be) that of the SBOM Element. Document creation information is serialized in DocumentContext (along with NamespaceMap), and if the document creator wishes, SBOM creation information can override document creation information. So requiring a Document Element in addition to an SBOM Element in the serialized bytes is a departure from v2, not consistent with it. The logical model should allow serialization of a single SBOM Element plus context, assorted annotations, relationships, licenses, identities, etc., just as v2 allows. Dave -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#4294): https://lists.spdx.org/g/Spdx-tech/message/4294 Mute This Topic: https://lists.spdx.org/mt/87732037/21656 Group Owner: spdx-tech+ow...@lists.spdx.org Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
