No Array root


David Kemp
 

William,

I typed in the SBOM example from the model diagram.
I then modified it to move the element of type SBOM from the beginning to the array of elements.

Neither the original nor the modified JSON-LD serialized file has an element of type SpdxDocument containing statements about the serialized file.  This is good :-).  But if in addition to the three elements (SBOM, Person, Package) there were a fourth SpdxDocument element, it would replace and eliminate the need for ExternalMap by providing URL, elements, and verification information, simplifying the model.

Neither the original nor the modified file has an array as root.  In example2 the root object still has creation/default properties, and it has external elements, and it has element values.  The difference is that the element values are all serialized together.  There is no need for a special rule that you can nest values one level deep, because there is no nesting at all.

Question: Is the second file a valid serialization?  Is there any reason to use a special nested JSON-LD serialization instead of keeping all the elements together in an array?

Original:
{
  SBOM: ...
  creationInfo: ...
  externalMap: ...
  elements: [
    Person: ...
    Package: ...
  ]
}

Modified, Not nested:
{
  creationInfo: ...
  externalMap: ...
  elements: [
    SBOM: ...
    Person: ...
    Package: ...
  ]
}

In my opinion, it is clearer to always say "this file contains these 3 elements", instead of saying "this file contains this element and two other elements nested inside it".  When hashing the SBOM element the hash doesn't cover other elements - this is more obvious when one SBOM contains another SBOM where the second isn't nested two levels deep.

Regards,
David


Gary O'Neall
 

My preference would be the second non-nested for 2 reasons:

  • It is similar and more compatible with the current serialization in JSON (not JSON-LD)
  • It is simpler to deserialize using an object oriented deserializer (like Jackson)

 

From: Spdx-tech@... <Spdx-tech@...> On Behalf Of David Kemp
Sent: Tuesday, August 9, 2022 11:35 AM
To: SPDX-list <Spdx-tech@...>
Subject: [spdx-tech] No Array root

 

William,

 

I typed in the SBOM example from the model diagram.
I then modified it to move the element of type SBOM from the beginning to the array of elements.

Neither the original nor the modified JSON-LD serialized file has an element of type SpdxDocument containing statements about the serialized file.  This is good :-).  But if in addition to the three elements (SBOM, Person, Package) there were a fourth SpdxDocument element, it would replace and eliminate the need for ExternalMap by providing URL, elements, and verification information, simplifying the model.

Neither the original nor the modified file has an array as root.  In example2 the root object still has creation/default properties, and it has external elements, and it has element values.  The difference is that the element values are all serialized together.  There is no need for a special rule that you can nest values one level deep, because there is no nesting at all.

Question: Is the second file a valid serialization?  Is there any reason to use a special nested JSON-LD serialization instead of keeping all the elements together in an array?

Original:
{

  SBOM: ...
  creationInfo: ...
  externalMap: ...
  elements: [

    Person: ...

    Package: ...

  ]
}

Modified, Not nested:
{

  creationInfo: ...

  externalMap: ...

  elements: [

    SBOM: ...

    Person: ...

    Package: ...
  ]

}

In my opinion, it is clearer to always say "this file contains these 3 elements", instead of saying "this file contains this element and two other elements nested inside it".  When hashing the SBOM element the hash doesn't cover other elements - this is more obvious when one SBOM contains another SBOM where the second isn't nested two levels deep.

Regards,
David


Sebastian Crane
 

Dear David,

With my tech-hat on, I would greatly prefer your second, modified
example. It's much easier to process with the programming languages I
use, which are of the functional paradigm and thus get along really well
with flat arrays or maps. Nesting means hard-coding extra logic to
extract the individual Elements out the extra structure.

Also, donning my outreach-hat now, I'd fully agree with your final
statement; I think the communication for 3.0 (both for publicity and
education) will be improved by prioritising the role of invididual,
atomic and discrete Elements.

Best wishes,

Sebastian

On Tue, Aug 09, 2022 at 02:34:47PM -0400, David Kemp wrote:
William,

I typed in the SBOM example from the model diagram.
I then modified it to move the element of type SBOM from the beginning to
the array of elements.

Neither the original nor the modified JSON-LD serialized file has an
element of type SpdxDocument containing statements about the serialized
file. This is good :-). But if in addition to the three elements (SBOM,
Person, Package) there were a fourth SpdxDocument element, it would replace
and eliminate the need for ExternalMap by providing URL, elements, and
verification information, simplifying the model.

Neither the original nor the modified file has an array as root. In
example2 the root object still has creation/default properties, and it has
external elements, and it has element values. The difference is that the
element values are all serialized together. There is no need for a special
rule that you can nest values one level deep, because there is no nesting
at all.

Question: Is the second file a valid serialization? Is there any reason to
use a special nested JSON-LD serialization instead of keeping all the
elements together in an array?

Original:
{
SBOM: ...
creationInfo: ...
externalMap: ...
elements: [
Person: ...
Package: ...
]
}

Modified, Not nested:
{
creationInfo: ...
externalMap: ...
elements: [
SBOM: ...
Person: ...
Package: ...
]
}

In my opinion, it is clearer to always say "this file contains these 3
elements", instead of saying "this file contains this element and two other
elements nested inside it". When hashing the SBOM element the hash doesn't
cover other elements - this is more obvious when one SBOM contains another
SBOM where the second isn't nested two levels deep.

Regards,
David





William Bartholomew (CELA)
 

The logical model is indifferent, this would live in the serialization layer, and I'd like to give serialization formats the flexibility since they may have technical constraints or conventions that make one option necessary or preferrable.

We previously decided that nesting was allowed, preferred to be restricted to one level, but you do not have to use nesting, you can keep flat if that's your preference. Nested and not nested are semantically equivalent.

The "root" will be dependent on the serialization format, again due to technical constraints. Because of this I'd like to keep the "root" as simple as possible, for example, I'm reluctant to add support for defaults and external/namespace maps to the "root" because this is already supported by collections, if you want to use those features then put your elements in a collection. Otherwise, we need to create a new type that looks like a collection in most ways but isn't a collection, that will lead to more confusion, not less ("if you want to collect multiple elements together put them in a collection, unless you want to put them in the root of a document in which case you can put them in an array, and then you put the maps over in these properties which are the same as the properties on collection but this isn't a collection it just looks like one" is not a sentence I want to have to write again 😊).

On the call I mentioned I wanted to talk a little more about optimizations a serializer might want to implement, it's relevant to this conversation so I'll include it here. The "data types" (on the right-hand side of the model) have struct semantics, in other words, if the fields have the same values then the structs are the same. When serializing a serializer could collapse all structs with the same value and replace them with a short identifier (that's only valid within that serialization), and on deserializing it expands the structs back to individual instances. This is more flexible than defaults because it can support collapsing multiple repeated values into individual short identifiers and some serializations already have this concept built in.

For a real-world example, let's say I create an Office SPDX document by combining the Word, Excel, Outlook, and PowerPoint SPDX documents. These products were built independently and there will be duplication in the creation information within each product but not across the products. They also depend on shared components that will have common creation information across the products. A serializer could collapse out all the common creation information into a file-level hash of identifier -> creation information without affecting the canonical or semantic meaning of the elements.

One interesting feature of YAML for example, is that it allows you to attach an "anchor" to a value and then use aliases to re-use that value elsewhere in the document. So on the first instance of a creation information, you could attach an "anchor" (I'd use the canonical hash of the creation information as the anchor) and then every subsequent instance of that same creation information could be replaced with an "alias". See here for an example: https://yaml101.com/anchors-and-aliases/. This same concept exists, or can be easily implemented, in other serializations, for example, in JSON you could have a "@anchors": { "a1b2c3": { arbitrary_json }, ... } property that provides the same capability.

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.

-----Original Message-----
From: Spdx-tech@... <Spdx-tech@...> On Behalf Of Sebastian Crane via lists.spdx.org
Sent: Tuesday, August 9, 2022 12:23 PM
To: Spdx-tech@...
Subject: [EXTERNAL] Re: [spdx-tech] No Array root

Dear David,

With my tech-hat on, I would greatly prefer your second, modified example. It's much easier to process with the programming languages I use, which are of the functional paradigm and thus get along really well with flat arrays or maps. Nesting means hard-coding extra logic to extract the individual Elements out the extra structure.

Also, donning my outreach-hat now, I'd fully agree with your final statement; I think the communication for 3.0 (both for publicity and
education) will be improved by prioritising the role of invididual, atomic and discrete Elements.

Best wishes,

Sebastian


On Tue, Aug 09, 2022 at 02:34:47PM -0400, David Kemp wrote:
William,

I typed in the SBOM example from the model diagram.
I then modified it to move the element of type SBOM from the beginning
to the array of elements.

Neither the original nor the modified JSON-LD serialized file has an
element of type SpdxDocument containing statements about the
serialized file. This is good :-). But if in addition to the three
elements (SBOM, Person, Package) there were a fourth SpdxDocument
element, it would replace and eliminate the need for ExternalMap by
providing URL, elements, and verification information, simplifying the model.

Neither the original nor the modified file has an array as root. In
example2 the root object still has creation/default properties, and it
has external elements, and it has element values. The difference is
that the element values are all serialized together. There is no need
for a special rule that you can nest values one level deep, because
there is no nesting at all.

Question: Is the second file a valid serialization? Is there any
reason to use a special nested JSON-LD serialization instead of
keeping all the elements together in an array?

Original:
{
SBOM: ...
creationInfo: ...
externalMap: ...
elements: [
Person: ...
Package: ...
]
}

Modified, Not nested:
{
creationInfo: ...
externalMap: ...
elements: [
SBOM: ...
Person: ...
Package: ...
]
}

In my opinion, it is clearer to always say "this file contains these 3
elements", instead of saying "this file contains this element and two
other elements nested inside it". When hashing the SBOM element the
hash doesn't cover other elements - this is more obvious when one SBOM
contains another SBOM where the second isn't nested two levels deep.

Regards,
David





Sean Barnum
 

The 2nd version is not a valid json-ld serialization.

I would strongly agree with William’s comments below about not trying to put a bunch of logical model content onto any sort of anonymous root structure that does not align to the model.

The good news is that William is correct. You can just use a Collection element as your root structure and get what you are looking for.

Literally, you should be able to add the following lines just above “creationInfo” ( I still disagree with breaking this out into a separate property) in your 2nd version and it would be valid json-ld as well as completely valid to the model and much simpler and fully granular than using an anonymous root structure:

                “@type”: “Collection”,

                “@id: “urn:spdx.dev:collection”,

 

 

I am also unclear why the example is using URNs for its @IDs . The IDs should be globally unique IRIs. I am hoping this is just shorthand and not meant to imply suggested form?

I am also unclear why the “urn:spdx.dev:doc” entry is in the externalMap as no such Element exists in the example.

 

sean

 

Sean Barnum

C – 703-473-8262

sbarnum@...

We are here to change the world!

signature_1388200754signature_1442303485signature_245889441signature_984325223signature_929545762

signature_1845422085

 

 

From: Spdx-tech@... <Spdx-tech@...> on behalf of William Bartholomew (CELA) via lists.spdx.org <willbar=microsoft.com@...>
Date: Tuesday, August 9, 2022 at 4:23 PM
To: seabass-labrax@... <seabass-labrax@...>, Spdx-tech@... <Spdx-tech@...>
Subject: [EXT] Re: [spdx-tech] No Array root

The logical model is indifferent, this would live in the serialization layer, and I'd like to give serialization formats the flexibility since they may have technical constraints or conventions that make one option necessary or preferrable.

We previously decided that nesting was allowed, preferred to be restricted to one level, but you do not have to use nesting, you can keep flat if that's your preference. Nested and not nested are semantically equivalent.

The "root" will be dependent on the serialization format, again due to technical constraints. Because of this I'd like to keep the "root" as simple as possible, for example, I'm reluctant to add support for defaults and external/namespace maps to the "root" because this is already supported by collections, if you want to use those features then put your elements in a collection. Otherwise, we need to create a new type that looks like a collection in most ways but isn't a collection, that will lead to more confusion, not less ("if you want to collect multiple elements together put them in a collection, unless you want to put them in the root of a document in which case you can put them in an array, and then you put the maps over in these properties which are the same as the properties on collection but this isn't a collection it just looks like one" is not a sentence I want to have to write again
😊).

On the call I mentioned I wanted to talk a little more about optimizations a serializer might want to implement, it's relevant to this conversation so I'll include it here. The "data types" (on the right-hand side of the model) have struct semantics, in other words, if the fields have the same values then the structs are the same. When serializing a serializer could collapse all structs with the same value and replace them with a short identifier (that's only valid within that serialization), and on deserializing it expands the structs back to individual instances. This is more flexible than defaults because it can support collapsing multiple repeated values into individual short identifiers and some serializations already have this concept built in.

For a real-world example, let's say I create an Office SPDX document by combining the Word, Excel, Outlook, and PowerPoint SPDX documents. These products were built independently and there will be duplication in the creation information within each product but not across the products. They also depend on shared components that will have common creation information across the products. A serializer could collapse out all the common creation information into a file-level hash of identifier -> creation information without affecting the canonical or semantic meaning of the elements.

One interesting feature of YAML for example, is that it allows you to attach an "anchor" to a value and then use aliases to re-use that value elsewhere in the document. So on the first instance of a creation information, you could attach an "anchor" (I'd use the canonical hash of the creation information as the anchor) and then every subsequent instance of that same creation information could be replaced with an "alias". See here for an example: https://yaml101.com/anchors-and-aliases/. This same concept exists, or can be easily implemented, in other serializations, for example, in JSON you could have a "@anchors": { "a1b2c3": { arbitrary_json }, ... } property that provides the same capability.

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.

-----Original Message-----
From: Spdx-tech@... <Spdx-tech@...> On Behalf Of Sebastian Crane via lists.spdx.org
Sent: Tuesday, August 9, 2022 12:23 PM
To: Spdx-tech@...
Subject: [EXTERNAL] Re: [spdx-tech] No Array root

Dear David,

With my tech-hat on, I would greatly prefer your second, modified example. It's much easier to process with the programming languages I use, which are of the functional paradigm and thus get along really well with flat arrays or maps. Nesting means hard-coding extra logic to extract the individual Elements out the extra structure.

Also, donning my outreach-hat now, I'd fully agree with your final statement; I think the communication for 3.0 (both for publicity and
education) will be improved by prioritising the role of invididual, atomic and discrete Elements.

Best wishes,

Sebastian


On Tue, Aug 09, 2022 at 02:34:47PM -0400, David Kemp wrote:
> William,
>
> I typed in the SBOM example from the model diagram.
> I then modified it to move the element of type SBOM from the beginning
> to the array of elements.
>
> Neither the original nor the modified JSON-LD serialized file has an
> element of type SpdxDocument containing statements about the
> serialized file.  This is good :-).  But if in addition to the three
> elements (SBOM, Person, Package) there were a fourth SpdxDocument
> element, it would replace and eliminate the need for ExternalMap by
> providing URL, elements, and verification information, simplifying the model.
>
> Neither the original nor the modified file has an array as root.  In
> example2 the root object still has creation/default properties, and it
> has external elements, and it has element values.  The difference is
> that the element values are all serialized together.  There is no need
> for a special rule that you can nest values one level deep, because
> there is no nesting at all.
>
> Question: Is the second file a valid serialization?  Is there any
> reason to use a special nested JSON-LD serialization instead of
> keeping all the elements together in an array?
>
> Original:
> {
>   SBOM: ...
>   creationInfo: ...
>   externalMap: ...
>   elements: [
>     Person: ...
>     Package: ...
>   ]
> }
>
> Modified, Not nested:
> {
>   creationInfo: ...
>   externalMap: ...
>   elements: [
>     SBOM: ...
>     Person: ...
>     Package: ...
>   ]
> }
>
> In my opinion, it is clearer to always say "this file contains these 3
> elements", instead of saying "this file contains this element and two
> other elements nested inside it".  When hashing the SBOM element the
> hash doesn't cover other elements - this is more obvious when one SBOM
> contains another SBOM where the second isn't nested two levels deep.
>
> Regards,
> David
>
>
>
>
>













David Kemp
 

The 2nd version is not a valid json-ld serialization.

How so?  https://json-ld.org/spec/latest/json-ld/#value-objects

I would strongly agree with William’s comments below about not trying to put a bunch of logical model content onto any sort of anonymous root structure that does not align to the model.

The logical model can contain as much or as little information about things as we want.  But things exist with or without a logical model.

https://blog.vaticle.com/what-is-a-knowledge-graph-5234363bf7f5 is an interesting read, and (of course) it gives examples of knowledge graph (logical model) nodes that describe things.  One example shows two people "Alice" and "Bob" who get married in a Marriage located in a City "London".  It should be obvious that Alice and Bob and London are not graph nodes, they are real people with DNA and experiences and streets and buildings.  A knowledge model *describes* things, it does not *define* things.

Moving from physical things to data things, an image (e.g., a png file) is a data thing.  A logical model could have an Image element that *describes* an image file, but does not *define* it.  If you wish to provide a counterexample, show the RDF or JSON-LD value of a 1920x1080 image with resolution and time and exposure settings with 2 million pixels, Image things are defined by standards like PNG and JPG, not, except extremely inefficiently, by knowledge graphs.

Moving from images to software, consider a tarfile containing 5 C source files.  The TAR specification defines the format of a tarfile, and a tarfile with C files does not contain SPDX elements, even though it can be described by both Package and File elements.

Finally, we arrive at Payload.  A Payload (serialized SPDX data) is a thing, not an element.  The Payload thing is *described* by an SpdxFile element, but it is not an element itself, any more than is a JPG file or a tarfile.

The requirement for Payload is that it can carry any combination of serialized elements (e.g., 5 identities, 5 annotations, 1 package + 2 files + 2 relationships, 1 SBOM + 4 files, 5 SBOMs, ...) and it must serialize and deserialize those elements without loss.  The simplest example of a 5-element Payload is just a list of 5 elements.  But for efficiency Payload also allows a namespace, prefixes, and default creation information. Payload also supports reference to other Payloads.  A payload thing is functionally equivalent to a tarfile - if you have 5 serialized elements you can put them in a tarfile and get them back out regardless of their element types - tar doesn't care.

The logical model doesn't have to provide any definition of Payload.  But the SPDX specification must define a Payload schema (a Datatype classifier that says any given sequence of bytes is or is not a valid SPDX file in some serialized format).   Here is a JADN Payload datatype:

Payload = Record                                  // Serialized file (or equivalent) for transferring Elements
   1 namespace        IRI optional                // Default namespace for Element ids in this file (rdf BASE)
   2 prefixes         NamespaceMap optional       // Namespace abbreviations used in this file (rdf PREFIX)
   3 createdBy        Link(Element) [0..*]        // File creation info and element defaults - Link(Actor)
   4 createdWhen      DateTime optional           // File creation info and element defaults
   5 specVersion      SemVer optional             // File creation info and element defaults
   6 profiles         ProfileIdentifier [0..*]    // File creation info and element defaults
   7 dataLicense      LicenseId optional          // File creation info and element defaults
   8 elements         Element [1..*]              // Element values, defined in this file or copied
   9 spdxDocumentId   Link(Element) optional      // Optional SpdxDocument element that describes this file
  10 spdxDocumentRefs Link(Element) [0..*]        // SpdxDocument elements that describe referenced files


The specifics can be debated and updated, but the fact that it is a datatype and not an Element cannot.  A logical model does not have any concept of references vs. values, a schema (JSON schema, XSD, etc) must, because the schema must *define* the difference between elements that are serialized within the payload and elements that come from other payloads.  It cannot be handwaved away with "oh, that's just serialization" if you want interoperability.

So we can define as much or as little about the Payload schema in the logical model as we wish, but it must be defined somewhere.

Regards,
David



On Tue, Aug 30, 2022 at 1:18 AM Sean Barnum <sbarnum@...> wrote:

The 2nd version is not a valid json-ld serialization.

I would strongly agree with William’s comments below about not trying to put a bunch of logical model content onto any sort of anonymous root structure that does not align to the model.

The good news is that William is correct. You can just use a Collection element as your root structure and get what you are looking for.

Literally, you should be able to add the following lines just above “creationInfo” ( I still disagree with breaking this out into a separate property) in your 2nd version and it would be valid json-ld as well as completely valid to the model and much simpler and fully granular than using an anonymous root structure:

                “@type”: “Collection”,

                “@id: “urn:spdx.dev:collection”,

 

 

I am also unclear why the example is using URNs for its @IDs . The IDs should be globally unique IRIs. I am hoping this is just shorthand and not meant to imply suggested form?

I am also unclear why the “urn:spdx.dev:doc” entry is in the externalMap as no such Element exists in the example.

 

sean

 

Sean Barnum

C – 703-473-8262

sbarnum@...

We are here to change the world!

signature_1388200754signature_1442303485signature_245889441signature_984325223signature_929545762

signature_1845422085

 

 

From: Spdx-tech@... <Spdx-tech@...> on behalf of William Bartholomew (CELA) via lists.spdx.org <willbar=microsoft.com@...>
Date: Tuesday, August 9, 2022 at 4:23 PM
To: seabass-labrax@... <seabass-labrax@...>, Spdx-tech@... <Spdx-tech@...>
Subject: [EXT] Re: [spdx-tech] No Array root

The logical model is indifferent, this would live in the serialization layer, and I'd like to give serialization formats the flexibility since they may have technical constraints or conventions that make one option necessary or preferrable.

We previously decided that nesting was allowed, preferred to be restricted to one level, but you do not have to use nesting, you can keep flat if that's your preference. Nested and not nested are semantically equivalent.

The "root" will be dependent on the serialization format, again due to technical constraints. Because of this I'd like to keep the "root" as simple as possible, for example, I'm reluctant to add support for defaults and external/namespace maps to the "root" because this is already supported by collections, if you want to use those features then put your elements in a collection. Otherwise, we need to create a new type that looks like a collection in most ways but isn't a collection, that will lead to more confusion, not less ("if you want to collect multiple elements together put them in a collection, unless you want to put them in the root of a document in which case you can put them in an array, and then you put the maps over in these properties which are the same as the properties on collection but this isn't a collection it just looks like one" is not a sentence I want to have to write again
😊).

On the call I mentioned I wanted to talk a little more about optimizations a serializer might want to implement, it's relevant to this conversation so I'll include it here. The "data types" (on the right-hand side of the model) have struct semantics, in other words, if the fields have the same values then the structs are the same. When serializing a serializer could collapse all structs with the same value and replace them with a short identifier (that's only valid within that serialization), and on deserializing it expands the structs back to individual instances. This is more flexible than defaults because it can support collapsing multiple repeated values into individual short identifiers and some serializations already have this concept built in.

For a real-world example, let's say I create an Office SPDX document by combining the Word, Excel, Outlook, and PowerPoint SPDX documents. These products were built independently and there will be duplication in the creation information within each product but not across the products. They also depend on shared components that will have common creation information across the products. A serializer could collapse out all the common creation information into a file-level hash of identifier -> creation information without affecting the canonical or semantic meaning of the elements.

One interesting feature of YAML for example, is that it allows you to attach an "anchor" to a value and then use aliases to re-use that value elsewhere in the document. So on the first instance of a creation information, you could attach an "anchor" (I'd use the canonical hash of the creation information as the anchor) and then every subsequent instance of that same creation information could be replaced with an "alias". See here for an example: https://yaml101.com/anchors-and-aliases/. This same concept exists, or can be easily implemented, in other serializations, for example, in JSON you could have a "@anchors": { "a1b2c3": { arbitrary_json }, ... } property that provides the same capability.

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.

-----Original Message-----
From: Spdx-tech@... <Spdx-tech@...> On Behalf Of Sebastian Crane via lists.spdx.org
Sent: Tuesday, August 9, 2022 12:23 PM
To: Spdx-tech@...
Subject: [EXTERNAL] Re: [spdx-tech] No Array root

Dear David,

With my tech-hat on, I would greatly prefer your second, modified example. It's much easier to process with the programming languages I use, which are of the functional paradigm and thus get along really well with flat arrays or maps. Nesting means hard-coding extra logic to extract the individual Elements out the extra structure.

Also, donning my outreach-hat now, I'd fully agree with your final statement; I think the communication for 3.0 (both for publicity and
education) will be improved by prioritising the role of invididual, atomic and discrete Elements.

Best wishes,

Sebastian


On Tue, Aug 09, 2022 at 02:34:47PM -0400, David Kemp wrote:
> William,
>
> I typed in the SBOM example from the model diagram.
> I then modified it to move the element of type SBOM from the beginning
> to the array of elements.
>
> Neither the original nor the modified JSON-LD serialized file has an
> element of type SpdxDocument containing statements about the
> serialized file.  This is good :-).  But if in addition to the three
> elements (SBOM, Person, Package) there were a fourth SpdxDocument
> element, it would replace and eliminate the need for ExternalMap by
> providing URL, elements, and verification information, simplifying the model.
>
> Neither the original nor the modified file has an array as root.  In
> example2 the root object still has creation/default properties, and it
> has external elements, and it has element values.  The difference is
> that the element values are all serialized together.  There is no need
> for a special rule that you can nest values one level deep, because
> there is no nesting at all.
>
> Question: Is the second file a valid serialization?  Is there any
> reason to use a special nested JSON-LD serialization instead of
> keeping all the elements together in an array?
>
> Original:
> {
>   SBOM: ...
>   creationInfo: ...
>   externalMap: ...
>   elements: [
>     Person: ...
>     Package: ...
>   ]
> }
>
> Modified, Not nested:
> {
>   creationInfo: ...
>   externalMap: ...
>   elements: [
>     SBOM: ...
>     Person: ...
>     Package: ...
>   ]
> }
>
> In my opinion, it is clearer to always say "this file contains these 3
> elements", instead of saying "this file contains this element and two
> other elements nested inside it".  When hashing the SBOM element the
> hash doesn't cover other elements - this is more obvious when one SBOM
> contains another SBOM where the second isn't nested two levels deep.
>
> Regards,
> David
>
>
>
>
>