Thanks for summarizing this David, if you have a chance could you show what a unit of transfer file would look like (JSON, YAML, ... any is fine). I've put a few comments in below.
Sent from Outlook<http://aka.ms/weboutlook> ________________________________ From: Spdx-tech@lists.spdx.org <Spdx-tech@lists.spdx.org> on behalf of David Kemp via lists.spdx.org <dk190a=gmail....@lists.spdx.org> Sent: Thursday, March 10, 2022 5:41 PM To: SPDX-list <Spdx-tech@lists.spdx.org> Subject: [EXTERNAL] [spdx-tech] Serialization, Integrity and the logical model For the punch list and signature/hash discussions: * Elements are metadata about "things". * A unit of transfer is a thing like a file or package * A unit of transfer contains serialized data used to transfer one or more Elements * A Document Element is metadata about a unit of transfer, not the UoT itself. * Like a file or package, a unit of transfer exists independently of whether metadata has ever been created to describe it. [William] Would this be valid though? If I sent you a "unit of transfer" that does not have a Document element I wouldn't consider that to be valid. An analogy would be a JPEG file, it contains the serialized image data, but it also had a header, without that header it is no longer a JPEG file. Yes, you may be able to still interpret the remaining data, but you can't claim it's a JPEG. * Integrity check values (ICVs) can be computed over any sequence of bytes including a UoT. [William] Since a Unit of Transfer contains elements but is not an element how do you attach the ICV to the Unit of Transfer? * Serializing multiple elements into a UoT allows a single ICV to provide integrity over that collection of elements. * Serializing a single element into a UoT allows an ICV to provide integrity over that element independently of all other elements. [William] I'm struggling to imagine what this looks like so a physical example would really help. My specific struggle is with what the Document, UnitOfTransfer, and associated ICV look like when serialized. As a reminder, the attached diagram (and my serialized versions of William's Relationship examples that Nisha graphed) illustrate that a logical model does not define serialization -- multiple serializations exist for the same logical model. ExternalMap and NamespaceMap exist to support Element serialization; they do not exist in logical / deserialized Elements. [William] One specific requirement was that we can retain the ExternalMap and NamespaceMap when deserializing and serializing, even across different formats. I think this requirement then requires that information to be in the logical model so that it isn't lost. The logical model<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fspdx%2Fmeetings%2Fblob%2Fmain%2Ftech%2FModel.png&data=04%7C01%7Cwillbar%40microsoft.com%7Cf6d5be04b4e34d3a4c2e08da03003cd9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637825596808207995%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=kqAhq1uIt%2FS3UYTX1gv3vv3JhNrGx7JI4HBBAF5pWSA%3D&reserved=0> has a question "should namespace map be on collection or doc?" Because Collection, Document, BOM, and SBOM are logical elements, namespace map doesn't apply to any of them. Only when Document, BOM, or SBOM elements are serialized into a UoT does namespace map data exist. Proof: when a UoT is created the namespaces and prefix for each namespace are assigned. Two different UoTs could be created with different prefixes and namespaces; but after deserialization the Elements from each UoT are identical. [William] I want to separate this into two parts. Yes, once deserialized the elements are identical. However, the NamespaceMap is kept in the logical model so that when you serialize back out you can repeat the original map process. Dave -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#4394): https://lists.spdx.org/g/Spdx-tech/message/4394 Mute This Topic: https://lists.spdx.org/mt/89702111/21656 Group Owner: spdx-tech+ow...@lists.spdx.org Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
