On Tue, Mar 15, 2022 at 11:49 AM Sean Barnum <[email protected]> wrote:
> I believe I have some significant disagreements with some of the > discussions here regarding “Unit of Transfer” and Document. > > > > Based on the modeling discussions that have occurred to date and our > current model I would assert that a “Unit of Transfer” is an actual file > containing serialized SPDX3 Element content. > *[dpk] *Yes. > This content could be any Elements including Documents, SBOMs, File > Artifacts, Relationships, etc or any combination of them. With SPDX3 there > is no constraining limitation on what content can be conveyed. It could be > a single Element of any kind or any number of separate or related Elements. > *[dpk] *Yes. > This file containing serialized SPDX3 Element content could also be > serialized in any supported serialization. > > Metadata about such a “Unit of Transfer” serialized file should be > represented in SPDX3 as a File Artifact since it is just a file. > *[dpk] *Yes. Metadata about a "Unit of Transfer" can also be represented as a Document Element which includes additional properties beyond the File metadata, in particular the list of Elements (the collection) serialized in the Unit of Transfer, perhaps a serialization format property. The Document collection lists only Elements contained in the Unit of Transfer, as opposed to the BOM collection which lists all Elements in the BOM regardless of whether or how those Elements are serialized. > As such a verifiedBy ICV can be easily associated with it the same as any > other File Artifact. This would give verification of a serialized body of > content. A Unit of Transfer” serialized file utilizing a different > serialization would have a different ICV associated. > *[dpk] *Yes. > I would assert that based on all of the model development over the last >1 > year, the Document Element does not express metadata about a “Unit of > Transfer”. Rather it is a simple “bundle” collection Element of other SPDX3 > Elements. It is pure SPDX3 Element at the model level and not tied to any > serialization or exchange use case. > *[dpk]* The word "document" (as in "JSON document" or "XML document" or "PDF document" or "Word document") is a sequence of bytes. Metadata about a document would logically be called a Document element. If there is a need for an Element that is a bundle of Elements without regard to serialization, perhaps it should be called "Bundle". Metadata about a Unit of Transfer could be called UnitOfTransfer instead of Document. But as described above, metadata about a Unit of Transfer needs SPDX-specific info (list of Elements) that isn't applicable to files in general. So the naming options are: A: metadata about serialized SPDX document: Document, collection of logical elements: Bundle B: metadata about serialized SPDX document: UnitOfTransfer, collection of logical elements: Document I vote for A, but either will work. > The NamespaceMap and ExternalMap are very intentionally attached to > Collection at the model level to support the requirements that William > calls out below. > > That is NamespaceMap is intended to be namespace prefix hints for > serialization independent of which serialization is chosen. How those > prefixes are expressed may differ from serialization to serialization but > having them expressed at the model level yields what consistency is > possible. > The ExternalMap is intended to provide useful detail for any Elements > referenced or included by copy in a given body of Element content but not > originally defined within that particular body of content. This is > independent of any namespace choices as a body of Element content could > utilize multiple different namespaces for content originally defined within > it and externally defined elements could use different namespaces or the > same ones used for included originally defined Elements. The ExternalMap > yields useful detail on things like how to verify externally defined > content, where externally defined content was defined, where to find > externally defined content, etc. Again, the ExternalMap is independent of > any particular serialization form or any particular instance of > serialization. The same ExternalMap for a body of content is relevant even > across multiple serializations of that content across multiple different > forms of serialization. > *[dpk]* Yes. You use the word "model" to refer to the logical model, but there are two other models: * information model (syntax-independent serialization) * data model (syntax-specific serialization) The logical model consists of "Resource Descriptions", whereas information and data models consist of "Schemas" that define serialized data rather than describe entities (including physical entities like the Statue of Liberty that aren't data). The information model defines data used in serialization without regard to data format, therefore "consistency from serialization to serialization" can be accomplished whether or not prefixes and external references are defined in the logical model. This is not an argument that the logical model should exclude anything. It is an observation that serialization serializes Elements and that Elements do not contain prefixes unless they are serialized. Elements do not contain "externally defined content" because the distinction between internal and external exists only in serialized Units of Transfer. The logical model, being a description, can certainly describe things other than Elements if desired. > All of these details have been extensively discussed within the 3T-SBOM > and SPDX3 community and I would assert that the model design is very > intentionally specified to the above description. > > Further, I think it is critical that it remain so. Any fundamental change > to any of these things (how to represent a serialized SPDX3 “Unit of > Transfer” in SPDX3, what a Document is, what NamespaceMap is, and what > ExternalMap is) will cascade into fragmenting other design decisions that > were based on these fundamental designs. > > > > </my_two_cents> > > > > sean > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#4415): https://lists.spdx.org/g/Spdx-tech/message/4415 Mute This Topic: https://lists.spdx.org/mt/89702111/21656 Group Owner: [email protected] Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
