I mentioned on the tech call that I was concerned about moving many of the properties from Document to Element.
I think of these properties as "creator" properties since they relate to the creation of the SPDX document, whether created by tools or humans. Below is the list of properties I consider "creator" properties: * specVersion * created * createdBy * profile * dataLicense I would like to frame up the discussion a bit more to help us get to some closure on the issue. First - I would propose we title the issue "Creator Properties" and frame the problem as where the Creator Properties belong - on each element, or on the Document that contains all the elements. I want to be clear that the meaning of Creator is the Creator of the Document containing the elements or the element metadata, not the creator of the element itself. For example, if Microsoft creates an application Word and there is and SBOM for Word created by ACME Source Analysis, the Creator Information in the Word SBOM element would indicate Acme Source Analysis, not Microsoft. In SPDX 2.2, the Creator Properties exist only at the document level and are properties of the SpdxDocument. In the model proposed by William and Sean, Creator Properties belong to the Element. SpdxDocument is subclassed from Element so it is unchanged, but each element can now optionally contain all of the Creator Properties. Below are my concerns on the current model proposal: * Size of SPDX documents: If each element contains all of the Creator Properties, the size of a document would be significantly larger. Each file, package, snippet, annotation, relationship could contain this additional information. For the Kubernetes-source.spdx file, there are 23,384 elements. Adding Creator Properties to each element with an estimated size of 65 bytes per element would add 1.5 megabytes. Adding this information to the relationships would add another 1.5 megabytes. * Duplication: The semantics of the Document class and Creator Properties in SPDX 2.2 apply to all elements in the document. Does this still hold in the new model proposal? Does it only apply if the optional creator properties are not present? If they are both present, which takes precedence? It seems like we are duplicating information in a normal document exchange where the Document is always present. * Complexity for consumers: In the SPDX 2.2 model, you check the creator information once and can quickly determine if the document meets your needs as a consumer from a creator point of view. In the proposed model, the entire graph would need to be parsed and some complex logic used to determine if it meets the needs. For example, if you are using a document for vulnerability analysis and only some of the elements meet that profile, can you use it? * Confusion between creator of the element and creator of the Document element metadata - Created date - is that the created date of the metadata or the element? To someone not involved in the SPDX standard discussion, they may logically assume that the creator information refers to the creator of the element in the same way the packageName, originator, etc. is data about the element, not data about the metadata. I can think of a couple advantages to the current model proposal: * Simplicity for the producer: If the elements are gathered from other creator sources and you want to produce a new document, you can simply copy the elements. In the SPDX 2.2 model, you would either need to analyze the SPDX document sources to make sure they comply with the profile or create multiple SPDX documents for the different profiles that it adheres to. * A single element contains useful information without having to reference the Document making consumer analysis easier for some use cases. To get closure on this, I would like to structure some criteria and a set of alternatives. Here's my proposed criteria: * Simplicity for producers * Simplicity for consumers * Size * Supports the following specific use cases: * Document exchange using files * Exchanging SBOM information using a stream * "Github" use case * Others? Here's my proposed alternatives: * Current SPDX 2.2 approach of Creator information at the document level * Current 3.0 proposed model * Separate creator object: Introduce a "CreatorInformation" class which contains the properties. Each element would have a required link to the CreatorInformation. The Document would have a list of all CreatorInformation present in the document. This would remove the duplication of creator information on each element and make it a bit easier for a consumer to scan all of the CreatorInformation objects without having to traverse the entire graph. * Current SPDX 2.2 approach with an additional property in Element which points back to the Document that is contained within. This would make it easier to extract the element for a producer but retain all of the original Document information in the streaming use case. * Others? If this framing and approach works, I'll share a Google Doc version we can all contribute to. I suggest we add this to the agenda for August 2nd. Gary ------------------------------------------------- Gary O'Neall Principal Consultant Source Auditor Inc. Mobile: 408.805.0586 Email: <mailto:g...@sourceauditor.com> g...@sourceauditor.com 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 (#4107): https://lists.spdx.org/g/Spdx-tech/message/4107 Mute This Topic: https://lists.spdx.org/mt/84360765/21656 Group Owner: spdx-tech+ow...@lists.spdx.org Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
