Summary of document serialization discussion


William Bartholomew (CELA)
 

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

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.

 


David Kemp
 

This way of describing things is still conflating element values with serialization.  There are Elements (RDF - https://www.w3.org/TR/rdf-syntax-grammar/#section-Syntax-node-property-elements - calls them Node Elements), and properties (RDF calls them property elements) that are nodes and edges in the logical graph.   A subset of nodes in the logical graph needs to be serialized into files using various data formats including JSON, RDF, Tag-Value, ....

* The content of files (whether individual files, package tarfiles or transfer units) does not exist in the graph
* Nodes can be created to describe files

Collections in a graph are edges from one node to another (in our case, from Collection to Element).  All Elements have IRIs, and all edges between Elements are IRIs. The job of serialization is to losslessly represent nodes and edges.   Treating one kind of edge (those outbound from the Collection node) differently from all other edges can be done, but it is an unnecessary complication.  And as mentioned in the meeting, collections can include collections, which can  include collections in an acyclic (non-recursive) graph.

Please provide a serialized example of SBOM A having SBOM B as a member, which in turn has "Document" C as a member, using a nested serialization, to contrast with linear serialization of the same nodes.  The canonicalization group has been discussing JSON as the canonical data format, but we also need nested tag-value and RDF serializations, to compare with linear tag-value and RDF serializations of the same nodes, in order to evaluate any proposals.

Regards,
Dave


On Tue, Jul 19, 2022 at 2:00 PM William Bartholomew (CELA) via lists.spdx.org <willbar=microsoft.com@...> wrote:

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

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.

 


David Kemp
 

On Tue, Jul 19, 2022 at 2:00 PM William Bartholomew (CELA) via lists.spdx.org <willbar=microsoft.com@...> wrote: 

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.


This is proof that serialization must be independent of the logical graph.  An XML structure with a single root MUST represent the identical.set of Element values as a JSON-LD structure with 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.


This is not true.  Regardless of what you call the element that describes the serialized data file (call it "SpdxFile" or "TransferUnit" to avoid confusion from using the name "Document"), it can be included in the array, and can be annotated and have relationships inbound and outbound just like every other element.  Yes the producer can choose to include or not include that element in the array, but there isn't any complicated set of rules to decide what the serialized data looks like, it's always a group of one or more elements serialized as an array (or map).  The SpdxFile element is either present or not in the array, depending on the producer's intention that the particular grouping of elements means something worth preserving in the graph.

A producer that serializes 6 license elements into a file, or 4 licenses in one file plus two licenses in another file, just wants to insert 6 licenses into the graph.  If the combination of file(s) that were used to convey them has no meaning to the producer, then he doesn't include SpdxFile elements that can be annotated.  If a consumer later decides that a group of 5 of those licenses has meaning as a group, the consumer can create an SpdxFile element that references the one or two files created (and signed, if end-to-end integrity is desired) by the producer.  That group of 5 can then be annotated by the consumer or anyone else.

Regards,
David


Sean Barnum
 

I think root is always an element (#1, #2, #3b) likely is the most effective approach.

 

 

Sean

 

 

From: Spdx-tech@... <Spdx-tech@...> on behalf of William Bartholomew (CELA) via lists.spdx.org <willbar=microsoft.com@...>
Date: Tuesday, July 19, 2022 at 2:00 PM
To: Spdx-tech@... <Spdx-tech@...>
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

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.

 


Sean Barnum
 

I wanted to offer a few observations here.

 

First, we should be careful not to conflate the concept/term “node and property elements” in RDF with with what we are calling Elements in our model. They are not the same thing. In the RDF graph, ALL nodes and edges (at a very granular level) are considered “elements” whereas in our model Elements are a certain subset of full objects that may include properties. Not all classes or nodes in the RDF graph are Elements. ALL nodes and edges in the RDF graph need to be serialized but they are not typically serialized at the same level of granularity that they exist in the RDF graph.

The issue of nesting in serializations is actually relatively straightforward.

In RDF (our model spec), properties are either DatatypeProperties which contain literal values or ObjectProperties which contain IDs of other objects. The IDs contained in ObjectProperties are either Element classes (subclasses of Element) or non-Element classes (e.g., IntegrityMethod). For serialization if we nest/embed the actual referenced objects for all ObjectProperties that are non-Elements but do not nest/embed the actual referenced objects for all ObjectProperties that are Elements we get a nice serialization at the granularity of Elements which is what we are looking for.

 

Collections in a graph are NOT edges. They are object nodes that are Elements. They have particular ObjectProperties called “element” and another called “rootElement” that represent edges in the graph to other Element object nodes. I agree that we want to avoid complexities of serialization rules treating edges on different kinds of objects differently but there should be no issues with simply treating different kinds of edges differently regardless of the kinds of objects they are on. This is a fundamental part of any serialization.

Using the above approach for nesting avoids the issue of collections including collections, supports consistent canonicalization, and keeps the domain graph clean.

 

I do not think this conflicts in any way with Wiliam’s post regarding serialization rules.

 

Sean

 

 

From: Spdx-tech@... <Spdx-tech@...> on behalf of David Kemp <dk190a@...>
Date: Wednesday, July 20, 2022 at 12:08 PM
To: William Bartholomew (CELA) <willbar@...>
Cc: Spdx-tech@... <Spdx-tech@...>
Subject: [EXT] Re: [spdx-tech] Summary of document serialization discussion

This way of describing things is still conflating element values with serialization.  There are Elements (RDF - https://www.w3.org/TR/rdf-syntax-grammar/#section-Syntax-node-property-elements - calls them Node Elements), and properties (RDF calls them property elements) that are nodes and edges in the logical graph.   A subset of nodes in the logical graph needs to be serialized into files using various data formats including JSON, RDF, Tag-Value, ....

* The content of files (whether individual files, package tarfiles or transfer units) does not exist in the graph
* Nodes can be created to describe files

Collections in a graph are edges from one node to another (in our case, from Collection to Element).  All Elements have IRIs, and all edges between Elements are IRIs. The job of serialization is to losslessly represent nodes and edges.   Treating one kind of edge (those outbound from the Collection node) differently from all other edges can be done, but it is an unnecessary complication.  And as mentioned in the meeting, collections can include collections, which can  include collections in an acyclic (non-recursive) graph.

Please provide a serialized example of SBOM A having SBOM B as a member, which in turn has "Document" C as a member, using a nested serialization, to contrast with linear serialization of the same nodes.  The canonicalization group has been discussing JSON as the canonical data format, but we also need nested tag-value and RDF serializations, to compare with linear tag-value and RDF serializations of the same nodes, in order to evaluate any proposals.

Regards,
Dave

 

On Tue, Jul 19, 2022 at 2:00 PM William Bartholomew (CELA) via lists.spdx.org <willbar=microsoft.com@...> wrote:

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:

a.       Allow the elements to be transferred as an array. Root of serialization is an array of elements.

b.      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

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.

 


Sean Barnum
 

Oops.

After hitting send I realized I forgot to include an important exception in something I said below. The missing statement is in red below.

 

For serialization if we nest/embed the actual referenced objects for all ObjectProperties that are non-Elements but do not nest/embed the actual referenced objects for all ObjectProperties that are Elements we get a nice serialization at the granularity of Elements which is what we are looking for. There would be one specific exception to this rule and that is for the “element” ObjectProperty on Collection where the referenced objects would be nested/embedded only at a single level of depth.

 

Sorry for the oversight.

 

sean

 

 

From: Sean Barnum <sbarnum@...>
Date: Tuesday, July 26, 2022 at 10:41 AM
To: David Kemp <dk190a@...>, William Bartholomew (CELA) <willbar@...>
Cc: Spdx-tech@... <Spdx-tech@...>
Subject: Re: [EXT] Re: [spdx-tech] Summary of document serialization discussion

I wanted to offer a few observations here.

 

First, we should be careful not to conflate the concept/term “node and property elements” in RDF with with what we are calling Elements in our model. They are not the same thing. In the RDF graph, ALL nodes and edges (at a very granular level) are considered “elements” whereas in our model Elements are a certain subset of full objects that may include properties. Not all classes or nodes in the RDF graph are Elements. ALL nodes and edges in the RDF graph need to be serialized but they are not typically serialized at the same level of granularity that they exist in the RDF graph.

The issue of nesting in serializations is actually relatively straightforward.

In RDF (our model spec), properties are either DatatypeProperties which contain literal values or ObjectProperties which contain IDs of other objects. The IDs contained in ObjectProperties are either Element classes (subclasses of Element) or non-Element classes (e.g., IntegrityMethod). For serialization if we nest/embed the actual referenced objects for all ObjectProperties that are non-Elements but do not nest/embed the actual referenced objects for all ObjectProperties that are Elements we get a nice serialization at the granularity of Elements which is what we are looking for.

 

Collections in a graph are NOT edges. They are object nodes that are Elements. They have particular ObjectProperties called “element” and another called “rootElement” that represent edges in the graph to other Element object nodes. I agree that we want to avoid complexities of serialization rules treating edges on different kinds of objects differently but there should be no issues with simply treating different kinds of edges differently regardless of the kinds of objects they are on. This is a fundamental part of any serialization.

Using the above approach for nesting avoids the issue of collections including collections, supports consistent canonicalization, and keeps the domain graph clean.

 

I do not think this conflicts in any way with Wiliam’s post regarding serialization rules.

 

Sean

 

 

From: Spdx-tech@... <Spdx-tech@...> on behalf of David Kemp <dk190a@...>
Date: Wednesday, July 20, 2022 at 12:08 PM
To: William Bartholomew (CELA) <willbar@...>
Cc: Spdx-tech@... <Spdx-tech@...>
Subject: [EXT] Re: [spdx-tech] Summary of document serialization discussion

This way of describing things is still conflating element values with serialization.  There are Elements (RDF - https://www.w3.org/TR/rdf-syntax-grammar/#section-Syntax-node-property-elements - calls them Node Elements), and properties (RDF calls them property elements) that are nodes and edges in the logical graph.   A subset of nodes in the logical graph needs to be serialized into files using various data formats including JSON, RDF, Tag-Value, ....

* The content of files (whether individual files, package tarfiles or transfer units) does not exist in the graph
* Nodes can be created to describe files

Collections in a graph are edges from one node to another (in our case, from Collection to Element).  All Elements have IRIs, and all edges between Elements are IRIs. The job of serialization is to losslessly represent nodes and edges.   Treating one kind of edge (those outbound from the Collection node) differently from all other edges can be done, but it is an unnecessary complication.  And as mentioned in the meeting, collections can include collections, which can  include collections in an acyclic (non-recursive) graph.

Please provide a serialized example of SBOM A having SBOM B as a member, which in turn has "Document" C as a member, using a nested serialization, to contrast with linear serialization of the same nodes.  The canonicalization group has been discussing JSON as the canonical data format, but we also need nested tag-value and RDF serializations, to compare with linear tag-value and RDF serializations of the same nodes, in order to evaluate any proposals.

Regards,
Dave

 

On Tue, Jul 19, 2022 at 2:00 PM William Bartholomew (CELA) via lists.spdx.org <willbar=microsoft.com@...> wrote:

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:

a.       Allow the elements to be transferred as an array. Root of serialization is an array of elements.

b.      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

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.

 


David Kemp
 

All of this complexity and special cases is unnecessary. There is no need for variant syntaxes and decision trees to accommodate the use cases discussed last week. One serialization structure (for all syntaxes) addresses all of:
1) single elements, non-contextual collections, streaming, etc where annotating the serialized data is unnecessary
2) SBOMs where annotating and referencing the serialized SBOM collection of elements is necessary
3) adding annotation after the fact to a subset of elements serialized in one or more files [ 1) and/or 2) ] while preserving source integrity
 
The "root" of serialization is always an object.  One of the properties of that object is an array of element values.  That array can have a single element or more. It can have an SPDX-File element that can be annotated for use cases where it's useful, omitted where it's not, and can be created after the original serialized file(s).

David


On Tue, Jul 26, 2022 at 10:41 AM Sean Barnum <sbarnum@...> wrote:

I think root is always an element (#1, #2, #3b) likely is the most effective approach.

 

 

Sean

 

 

From: Spdx-tech@... <Spdx-tech@...> on behalf of William Bartholomew (CELA) via lists.spdx.org <willbar=microsoft.com@...>
Date: Tuesday, July 19, 2022 at 2:00 PM
To: Spdx-tech@... <Spdx-tech@...>
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

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.