I think root is always an element (#1, #2, #3b) likely is the most effective approach.
Sean From: [email protected] <[email protected]> on behalf of William Bartholomew (CELA) via lists.spdx.org <[email protected]> Date: Tuesday, July 19, 2022 at 2:00 PM To: [email protected] <[email protected]> Subject: [EXT] [spdx-tech] Summary of document serialization discussion Proposed rules (and alternatives): 1. If you are transferring a single element and no additional context needs to be transferred, just transfer the single element. Root of serialization is a single element (the element being transferred). 1. If you are transferring one or more elements and additional context (such as the creator info of the anthology) needs to be transferred, place the elements in a collection and transfer the collection. Root of serialization is a single element (the collection element). 1. If you are transferring one or more elements and no additional context needs to be transferred, this was the sticking point and we had two options: 1. Allow the elements to be transferred as an array. Root of serialization is an array of elements. 2. Require the elements to be wrapped in a collection. Root of serialization is a single element (the collection element). 1. An alternative was proposed where the root of serialization is always an array of elements, even if it’s an array of one in scenario #1 and #2 above. Serialization implications: We end up with one of these three options for serialization: * Root is always an element (#1, #2, #3b). * Root is always an array (#4). * One significant concern I have with this is that if we ever have to attach additional information to the root it is a breaking change. We can work around this by making the root an object with a single property “elements” though at that stage I’d argue we’re just recreating “Collection” is a plain object instead of an “Element” (we originally had that design and moved away from it), we went to a lot of effort to make “Element” and “Collection” extremely lightweight so they could be used for scenarios like this. * Root is sometimes an element (#1, #2) or sometimes an array (#3a). Individual serializations may have constraints that require them to select a certain option or wrap an option in another option, for example, XML always has a single root, JSON-JD is always a list. When the root is an array, consumers lose any ability to “address” the root (e.g. if they wanted to attach annotations or other information to the root), it requires the producer to intend the consumer to be able to do this and to make the decision to wrap a collection around the elements, while the consumer could do this post facto there would be no shared identity with the producer. This was one of the reasons that SPDXID was required on all SPDX elements in 2.x, because it gave the consumer options to attach information even if that was not the intent of the producer, because the producer does not know all of the consumers use cases for the information or future use cases they may want to apply. Regards, William Bartholomew (he/him) – Let’s chat<https://outlook.office.com/bookwithme/user/[email protected]/meetingtype/SVRwCe7HMUGxuT6WGxi68g2?anonymous&ep=mlink> Principal Security Strategist Global Cybersecurity Policy – Microsoft My working day may not be your working day. Please don’t feel obliged to reply to this e-mail outside of your normal working hours. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#4686): https://lists.spdx.org/g/Spdx-tech/message/4686 Mute This Topic: https://lists.spdx.org/mt/92488223/21656 Group Owner: [email protected] Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
