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. ________________________________ From: David Kemp <[email protected]> Sent: Wednesday, November 24, 2021 10:42 AM To: William Bartholomew (CELA) <[email protected]> Cc: [email protected] <[email protected]> Subject: Re: [EXTERNAL] Re: [spdx-tech] ContextualCollection and CONTAINS Relationship 1. I think we need only two terms: * unit of transfer = little-d document (sequence of octets) = data that is signed or hashed when an arbitrary set of elements is serialized = Bundle / set of Elements plus context used to aid serialization. The unit of transfer is not a form of Collection because * Collection = Element that has an "elements" property of type (0..* Element) 2. I only mentioned bag because Henk raised the question of whether set was mathematically accurate. It comes down to whether the following are valid values of the "elements" property, and if there is any conceivable use case for ever allowing/using bags of Elements. I think set is sufficient, and would want to see a concrete example of the need for bag. * set: "elements": ["Package1", "Identity9", "Annotation3"] * bag: "elements": ["Package1", "Package1", "Package1", "Identity9", "Annotation3"] 3. little-c collection is an approachable term for a grouping/set of elements, but it is easily confused with the Collection class that is a grouping of elements structured as a parent Element + child Elements. I agree that a unit of transfer = little-c collection of one or more elements, but I disagree that a unit of transfer must be a parent Element plus its child Elements. In other words, I think it must be possible to serialize any random set of Elements "drawn from a deck of Elements" without regard to any big-C Collection relationships. I would call that a "bundle" rather than a "little-c collection". Regards, Dave On Wed, Nov 24, 2021 at 12:03 PM William Bartholomew (CELA) <[email protected]<mailto:[email protected]>> wrote: Let me split this question into a few questions for the community: 1. Do we agree that Set, Bag, etc. are specialized forms of Collection? 2. Are all subclasses of Collection, now and forever, going to have the same specialized semantics or could some subclasses be sets and others be bags? * If all the subclasses are the same now and we can’t imagine any possible scenario where that won’t be true or desired, then Collection should be the specialized form (Set or Bag or …). * If we know some will be different or we don’t want to commit to this always being true, then Collection should be the generalized form (Collection). 3. Even if Collection is a specialized form of collection is the general term Collection more approachable to the broader community (less technical and non-native English speakers)? The specification text either way would need to be specific. Regards, William Bartholomew (he/him) – Let’s chat<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Foutlook.office.com%2Ffindtime%2Fvote%3Fbook%3Dwillbar%40microsoft.com%26anonymous%26ep%3Dplink&data=04%7C01%7Cwillbar%40microsoft.com%7Cf24ffb0164b44f47037b08d9af7a25f6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637733761441308019%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=xy4LKeeFiA%2Fu6CI3xYa57bORNMdRC9S99dtOjaT8biw%3D&reserved=0> Principal Security Strategist Cybersecurity Policy – Digital Diplomacy -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#4269): https://lists.spdx.org/g/Spdx-tech/message/4269 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]] -=-=-=-=-=-=-=-=-=-=-=-
