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