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 (#4665): https://lists.spdx.org/g/Spdx-tech/message/4665
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]]
-=-=-=-=-=-=-=-=-=-=-=-
