Hi all, Might I suggest a change of subject line before this goes too far? I’m just thinking of the poor souls in the future grepping through the archives.
steve From: [email protected] <[email protected]> On Behalf Of Gary O'Neall Sent: 23 June 2022 22:33 To: 'David Kemp' <[email protected]>; 'SPDX Technical Mailing List' <[email protected]> Subject: Re: [spdx-tech] No SPDX tech meeting this week [External] Hi David, Definitely got me thinking about the serializations. A couple of thoughts: * Adding a prefix of “@” almost creates a JSON-LD serialization format since JSON-LD includes the concept of types and ID’s. I need to think about it some more, but we may just want to use JSON-LD as the “unoptimized” format. * Currently in JSON, we distinguish the type at the list level (e.g. separate packages array, files array, relationships array, etc.). This approach is closer to what many implementations expect. I still like the approach have the logical model having separate data types (or “structs”) for collections of properties we want to “optimize” in the serialization. Cheers, Gary From: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> On Behalf Of David Kemp Sent: Thursday, June 23, 2022 11:50 AM To: SPDX Technical Mailing List <[email protected]<mailto:[email protected]>> Subject: Re: [spdx-tech] No SPDX tech meeting this week SPDX v3 Document and Transfer Unit The SPDX v3 model https://github.com/spdx/spdx-3-model/blob/main/model.png<https://urldefense.com/v3/__https:/github.com/spdx/spdx-3-model/blob/main/model.png__;!!A3Ni8CS0y2Y!94o4laj-lgzzUrD1j33c2acdmc0nctOsm0EfjYP2XAUvyl__IAdttiXYVmPmZ03B11JBIHbleoegzOnD3HTR6A$> now shows Collection as not being an Element. This highlights the main difference between v2 and v3: v2 defines the structure of a document while v3 follows the 3T SBOM approach of defining the elements in a graph. V2 defines serialized data directly, while v3 defines Element content prior to serialization. In v3: 1) Everything is an Element 2) An Element is metadata about something (a file, a package, an identity), not the content of the thing described by the metadata 3) A file containing serialized data is a thing. An Element describing a file containing serialized data is metadata about that file. So the difference between Document as the structure of serialized data and Document as metadata about that file (an Element) is critical. The name of the type labeled Document in the model depends on whether that type defines serialized data or Element metadata about a file. In any case, the addition of serialized Examples to the model is very helpful; examples are unambiguously serialized data The simplest way to serialize Elements is without any optimization, just a list of independent elements without regard to their types or relationships. A Minimal Example would be a list of zero elements: [ ] A Minimal useful example would be a list of one element: [ {element1} ] A larger example would be a list of multiple serialized elements [ {element1}, {element2}, {element3} ] So the minimum useful example would have a list of one element with type Person, not Document. Unoptimized, it would be: [ { "type": "Person", "id": "urn:spdx.dev:iamwillbar", "specVersion": "3.0", "created": "2022-05-02T20:28:00.000Z", "profile": ["core"], "dataLicense": "CC0-1.0", "createdBy": "urn:spdx.dev:iamwillbar" } ] An unoptimized example with five elements would be a list of five objects, each with the same seven required properties. Any optimizations applied to the serialized data, such as factoring out common element properties and id namespace prefixes, makes the transfer unit smaller but does not change the elements contained in the transfer unit or the values of those elements. { "namespaces": {"": "urn:spdx.dev<https://urldefense.com/v3/__http:/spdx.dev__;!!A3Ni8CS0y2Y!94o4laj-lgzzUrD1j33c2acdmc0nctOsm0EfjYP2XAUvyl__IAdttiXYVmPmZ03B11JBIHbleoegzOkzYwjOxA$>:"}, "defaults": { "specVersion": "3.0", "created": "2022-05-02T20:28:00.000Z", "profile": ["core"], "dataLicense": "CC0-1.0", "createdBy": "iamwillbar" }, "elements": [ { "type": "Person", "id": "iamwillbar", } ] } This example optimized transfer unit is structured so that additional elements can be added efficiently. But it is NOT an element itself; it is the serialized data of a collection, not metadata about a collection. It does not have a type in JSON because JSON does not have types ("type" is not a reserved property name), in XML the outermost list or object would be a <TransferUnit> type. And it does not have an id because it is not an Element. Dave On Tue, Jun 21, 2022 at 9:57 AM Gary O'Neall <[email protected]<mailto:[email protected]>> wrote: Sorry for the late notice, but I just received a few emails of more people not being able to make this week’s tech call, so we’ll cancel today’s call. We’ll see you online next Tuesday. Best regards, Gary ------------------------------------------------- Gary O'Neall Principal Consultant Source Auditor Inc. Mobile: 408.805.0586 Email: [email protected]<mailto:[email protected]> 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 (#4602): https://lists.spdx.org/g/Spdx-tech/message/4602 Mute This Topic: https://lists.spdx.org/mt/91899918/21656 Group Owner: [email protected] Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
