I agree with #1. For example you should be able to transfer a single Annotation element without having to create an additional Document element just to hold it. If you are going to add a single annotation to somebody else's Package, there is no point in creating two Elements "Document -> Annotation" just so you can "refer to and re-use the collection". You can easily refer to and reuse the Annotation element all by itself. If you create 100 annotations (or just one), you have the choice of putting them in a Document that can be named and reused, or putting them in a Bundle without any collection Document so each Annotation Element exists individually. The serialization gives the creator the choice of using Document or Bundle, whichever they think is appropriate.
I don't disagree with #2, but serialization provides mechanism, not policy. It can be a tools rule that collection authors follow #2, but the serialization has to work correctly if it isn't. It certainly seems reasonable for a serialized Collection element to reference previously-created elements instead of copying their contents into the collection, and that's how I interpreted your earlier email. If Microsoft creates a half-megabyte canonical Package with 1000 File elements, do you really want to be forced to copy their data into your data in order to re-use it in your Collection? [*WillBar*] Nov 15: 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 > > We earlier discussed the meaning of verifiedUsing on artifacts as being the hash of the artifact, not a hash of the Element properties. We also need to be able to verify Elements (of all types including Identities, Annotations, etc) so that they can be referenced instead of copied. The serialization allows Elements themselves to be referenced and their values verified. Regards, Dave On Wed, Nov 24, 2021 at 3:50 PM William Bartholomew (CELA) < [email protected]> wrote: > Some of Sean's (I think) suggestions from yesterday's call were: > > 1. You should be able to transfer any element (including collections). > 2. If you transfer a Collection (or any of its subclasses) you must > transfer the "elements" referenced by the collection (and if any of those > are collections I assume this would be transitive), they are a unit. > > Drawing any set of elements for transfer would be a "Document", that is > the intent of that class, it's a collection with no presumption of shared > context. > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#4270): https://lists.spdx.org/g/Spdx-tech/message/4270 Mute This Topic: https://lists.spdx.org/mt/87265208/21656 Group Owner: [email protected] Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
