William, I agree with all requirements, and the slides were intended to illustrate the possibilities. People have been asking for v3 serializations; I'm close to having an information model and JSON serialized examples derived from the example graph showing how all of the requirements are met. Concrete examples should make it clear, and if the information model doesn't meet all the requirements then it needs to be fixed.
- In the IM Elements are never tied to Documents - Document is a synonym for Collection. I'm not sure what it means to "load up" a graph of elements - they are being loaded from some piece of data. But since each Element has an IRI it is certainly possible to extract a graph of IRIs from the rest of the Element data, and transfer it using some generic graph format like dot or plantuml. - An aggregate of Elements can itself be a Collection with an IRI, but that's why I proposed a "Bag" of Elements that doesn't have an IRI as another way to transfer an arbitrary pile of Elements into an air-gapped environment. - ElementMap (I call it ElementRef in the IM, but any name will do) exists precisely so that canonical Elements can be re-used instead of created anew. I hope concrete serialized examples will illustrate how all requirements are satisfied. Maybe before tomorrow's call ... Dave On Mon, Nov 15, 2021 at 1:29 PM William Bartholomew (CELA) < [email protected]> wrote: > Hi David, > > > > If I’ve interpreted this correctly (and I admit I may not have) this > sounds like the approach the SPDX 2.x uses where each file (document) has a > namespace and then all the identifiers within that file are relative to > that namespace. Those identifiers could be meaningful or meaningless > because they’re opaque to SPDX (although SPDX 2.x does impose some > structural requirements on the identifier). > > > > In the SPDX 3.x model you can still produce files with this same structure > if you want, you have complete control over the namespaces and identifiers > you use, so if you want to have a namespace per file and then unique > identifiers within that namespace that’s perfectly fine. > > > > However, over the last 18 months participants have expressed a few desired > requirements that led to us making the model more flexible while still > supporting that use case. Specifically: > > - Elements not being tied to documents. This was to support use cases > where you may not be transferring the elements and just want to load up a > graph of elements and traverse them. > - Being able to include an element that was originally created in one > document into another document (for example, to create an aggregate > document to transfer into an air-gapped environment). > - Encouraging re-use of elements when feasible. This becomes > interesting when we have more and more “canonical” SBOMs being produced > (i.e. the SBOM being produced by the original software creator rather than > a third-party). Re-using the canonical elements is preferrable to creating > new elements. > > > > This approaches aren’t mutually exclusive and I believe both are supported > today. > > > > Regards, > > > > William Bartholomew (he/him) – Let’s chat > <https://outlook.office.com/findtime/[email protected]&anonymous&ep=plink> > > Principal Security Strategist > > Cybersecurity Policy – Digital Diplomacy > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#4255): https://lists.spdx.org/g/Spdx-tech/message/4255 Mute This Topic: https://lists.spdx.org/mt/87076458/21656 Group Owner: [email protected] Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
