Re: [EXT] Re: [spdx-tech] Document Describes

Sean Barnum

I agree that in 2.2 all Elements were tied to Documents.

I believe the most fundamental change from 2.2 to 3.0 is that this is no longer true. This was a key principle for the 3T-SBOM collaboration and fundamental to many use cases.

In 3.0 Elements are Elements. A Document is an Element just like any other. A Document may contain other Elements but Elements can also exist independent of any Document.


For the model, Documents do not have sections. They contain/reference other Elements in their “element” property and they highlight key Elements (from their “element” property) of focus using their “rootElement” property.

Given the fact that the set of valid concrete Element types is evolving and open for extension (e.g., some model namespace other than core or software) hard limiting Document to explicit sections is not practical.

Each Element would explicitly declare its type in any serialization (@type in JSON-LD). Determining type of an Element should not depend on implicit inferencing based on serialization structure.


A given serialization could be defined where Elements in a Document are explicitly grouped into serialized sections but I would propose that this is not desirable for a default serialization as it adds significant complexity to serializing, deserializing and transforming between serializations while staying consistent to the model.

It also reduces the utility of existing ecosystem tools and requires specialized code to adapt to such tools.

In my experience it is more practical and effective to define the default serialization as close to the model as possible and if any other more specialized serializations (such as breaking Element types into sections) are desired to simply create transforms for them from the default serialization. In this way, the model-centric default serialization benefits from the ecosystem and serves as the hub for the wheel of serialization.


Does that make sense?





Sean Barnum

C – 703-473-8262


We are here to change the world!





From: David Kemp <dk190a@...>
Date: Tuesday, July 27, 2021 at 3:12 PM
To: Sean Barnum <sbarnum@...>
Cc: SPDX-list <Spdx-tech@...>
Subject: Re: [EXT] Re: [spdx-tech] Document Describes


My question was that in 2.2 every Element is known to be one of Document, Package, File, Snippet, OtherLicensingInfo, Relationship, or Annotation, because elements come only from Documents, and Documents have exactly those 7 sections.

If we have Elements that don't come from Documents, plus for those that do, Documents don't have sections, then there must be a list of 7 or 10 or whatever possible kinds of Element.

Concrete elements are instantiated, Abstract elements are not.  Given that you have an Element in your hand, and given that it does not have a Section name, what do you use to figure out what kind of element it is?





On Tue, Jul 27, 2021 at 11:24 AM Sean Barnum <sbarnum@...> wrote:

I am not sure if I am reading your comment correctly.

If you are suggesting that ContextualCollection and BOM should be abstract then I would disagree as there are use cases for these independent of SBOM and they need to be concrete so that such elements can be expressed.




Join { to automatically receive all group messages.