William started the discussion with a probative question: ** If we have an Element store/database, can we query the database to return one or more individual Elements?* Yes.
The result of the query can be one Identity element and nothing else, two Identity elements and nothing else, three File elements and nothing else, etc. Follow-on questions: ** If we serialize the Elements returned from the query into a Transfer Unit (a serialized file or sequence of bytes), does that file need to contain a Document Element in addition to the queried Elements? * No. The serialized collection of Elements has serialization-related information in addition to the serialized values of the Elements themselves, but that additional information is not an Element. If two File Elements are serialized, then two File elements are de-serialized, not two File Elements plus a Document Element. The additional information must include a unique ID for the Transfer Unit (its namespace) to allow it to be referenced from other Transfer Units, and references to Elements in other Transfer Units. It may include default values for some common element properties (Element creation information, SPDX spec version, SPDX profiles, Element data license), and a NamespaceMap to allow namespace abbreviation within the serialized data. ** If we query and serialize two File Elements into a Transfer Unit, can we also create a Document Element containing metadata about the Transfer Unit?* Yes. For auditing or other purposes, it is possible to create a Document Element in the Element database for none, some, or all of the Transfer Units that are created. Just as a disk file exists independently of and does not contain an SPDX File Element describing it, a Transfer Unit (file) exists independently of and does not contain an SPDX Document Element that describes it. The Document metadata can include information that does not exist in the Transfer Unit, and the Transfer Unit certainly includes information that isn't included in the metadata, just as with files and File Elements. ** Does every Collection have a context?* Yes. If the Element database is queried for every Element that has a "Y" in its Name property, the collection of elements returned are related simply by the criteria used to select them. If the Element database is queried for a single SBOM Element, that Element has a Collection property that lists all Elements that are part of the SBOM, regardless of whether they are returned in any particular query. If a Collection of Elements is serialized into a Transfer Unit, the Transfer Unit inherently contains those Elements. IF a Document Element is optionally created to describe that Transfer Unit, it has a Collection property listing the Elements contained in the Transfer Unit. Thus whether the Collection is a bundle of "unrelated" elements that are serialized together into a Transfer Unit, or a collection of elements in an SBOM, there is just one (abstract) Collection type. The model does not need a concrete "ContextualCollection" type; BOM and SBOM can extend the abstract Collection, as can Document metadata describing a Transfer Unit. If any other non-BOM collection types are defined, they can also extend Collection. There is always a reason/context for extending the Collection type. Dave -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#4473): https://lists.spdx.org/g/Spdx-tech/message/4473 Mute This Topic: https://lists.spdx.org/mt/90761006/21656 Group Owner: [email protected] Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
