Just catching up on this conversation (whew!).
A lot of good points made, many of which I agree with. I just wanted to add a couple of points – I won’t attempt to make these inline since it is spread across a couple of emails: * Hashing individual elements for integrity: In the SPDX 2.0 development, a few of us worked to come up with a method for this that would be implementable/practical and, in the end, did not succeed. With the addition of more talent on this issue, we may be able to solve this for 3.0. However, I would not make that assumption for the purposes of modeling. At least not until we have a proposal which has been tested by at least one implementation. If we do not have the ability to hash individual elements, having a class similar to the SPDX 2.0 SpdxDocument for verification would be quite important IMHO. * In the thread a comment was made the Document was introduced out of the 3T SBOM discussions having the same semantics as the STIX Bundle. This doesn’t represent my view. I have always wanted a Document element to provide the same semantics as SPDX 2.0 SpdxDocument both to solve issues such as integrity and to provide compatibility. The STIX Bundle, in my opinion, is quite different in semantic definition. My apologies if I somehow came across as stating the Document is the same as a STIX Bundle. * I still believe we need a class that provides similar features to the SPDX 2.0 SpdxDocument class – (e.g. integrity through Document checksums, ability to capture namespace information for higher fidelity serialization transformations). I believe the current model has a class with is close to providing this – just needs a bit of fine tuning. * I believe it should continue to be named Document for compatibility – but naming is secondary to getting the structure right * Although I don’t really see much value in having a class called Bundle with the exact same semantics as the STIX Bundle, I have no problem adding that to the model if others find it useful. One advantage to having the STIX Bundle in our model would make it clearer the difference between a Bundle and a Document. Regards, Gary From: [email protected] <[email protected]> On Behalf Of David Kemp Sent: Friday, November 5, 2021 10:17 AM To: William Bartholomew (CELA) <[email protected]> Cc: [email protected]; [email protected] Subject: Re: [EXTERNAL] Re: [spdx-tech] Collection member Elements Just one point for now: [Dave] Bundle (little-d document, non-contextual collection) is the unit of transfer for multiple independent/unrelated Elements in a single exchange, such as moving them from the Internet to a closed/internal environment. The fact of putting a bunch of Elements into a unit of transfer does not create any logical context/relationship among them. Once they have been transferred the unit of transfer disappears, leaving no trace of itself in the transferred set of Elements. If the unit of transfer is itself intended to become an Element with an IRI after the transfer is finished, then simply create and transfer a Collection or its subclass.. [WillBar] Document is intended to have the same purpose of Bundle, there was weeks of debate across both the 3T-SBOM and SPDX communities about whether Document should be renamed to Bundle, the decision was made not to. The tech group will need to have a discussion of a new requirement. The previous long discussion was whether to use "Document" or "Bundle" to refer to an Element that has the properties of Element and is now a subclass of Collection. The new proposal is to create a logical model class that is NOT an Element and does not exist in the current logical model. As described above, it has no IRI, no name, no creation info, nothing except the Elements to be transferred. It has the semantics of a STIX "Bundle", not a v2 or v3 "Document", so the previous discussion does not apply. Regards, Dave -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#4235): https://lists.spdx.org/g/Spdx-tech/message/4235 Mute This Topic: https://lists.spdx.org/mt/86776587/21656 Group Owner: [email protected] Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
