search

spdx / spdx-3-model

The model for the information captured in SPDX version 3 standard.
https://spdx.dev/use/specifications/
Other
71 stars 46 forks source link

Is it possible to create a serialized SPDX data (JSON-LD format) that doesn't use an SPDX Document? #932

Open goneall opened 4 days ago

goneall commented 4 days ago

In the development of the SPDX version 3 spec, there were some use cases where they wanted to publish an SPDX Element without wrapping it in an SPDX document.

I just attempted to do this for the listed licenses in the LicenseListPublisher utility.

It turned out to be somewhat impractical due to the following facts:

In the case of the LicenseListPublisher, this led me to wrapping the individual license along with the creator Agent in a single SPDX document.

Question: are there any cases where you would not take this approach? If not, should we simplify the spec by requiring an SPDX document on serializations?

sbarnum commented 1 day ago

It is definitely possible to create serialized SPDX data that does not use an SPDXDocument. While most common cases utilize SPDXDocument, there are other cases where it may not be desired and is thus explicitly and intentionally not required. When we discussed this issue at length and reached explicit consensus that it explicitly was not required several examples were given of such cases. I don't remember all of them off the top of my head but one such case was the desire for machine-to-machine (potentially stream based) exchange of a set (or even single instance) of Agent Elements. I may want to express and exchange a single Person Element representing myself with CreationInfo (non-Element class) content embedded inline within the JSON-LD serialized Person Element. In this case the createdBy property may simply contain a self-referential ID of the Person Element I am creating. It would make no sense to create an SPDXDocument for this. Expanding it a little, I could desire to express a set of Person Elements (one for each member of the SPDX Tech group) with me as the creator of these Elements. In such case, each Person Element could be defined and the createdBy for each could still reference the ID of the Person Element representing me. We cannot presume whether the createdBy Agent is or is not included in the serialization so there may be no external Elements. Even if there were external Elements we also cannot presume whether or not it is desired to provide any info beyond simply the IDs of those external Elements. ExternalMap is optional and offer the ability to provide further context for external IDs if desired (but not required).

Having more than one element typically requires a method of pointing to the "root" of the serialized graph so the code interpreting the serialized data knows where to start

While this may be desired in some cases it is explicitly and by design NOT required in all cases. This is exemplified not only in the core topic of this Issue (SPDXDocument is NOT required for all serializations of SPDX content) but also in the fact that even IF you chose to express an SPDXDocument or any ElementCollection it is still optional whether or not to include a 'root' property (it is only an optional hint if desired).

SpdxDocument is the preferred method of pointing to the root of the serialized graph (although there are other methods such as a Bundle)

I would disagree with this. The 'root' property is the preferred way of pointing to the root of a serialized graph of SPDX Elements IF it is desired to convey the graph as a collection of Elements and such a 'starting place' 'hint'. This is true for ANY ElementCollection. SpdxDocument is not explicitly preferred over Bundle. One or the other could be preferential based on the context. While I would agree that SpdxDocument would likely be more commonly used than Bundle, whether one or the other is 'preferred' is an implicit bias of a particular adopter or use case and not an explicit assertion at a global level within the spec.

You can use an external element for the Agent, but to do so you would want to record information about the external element

A given user MAY want to record information about the external element but it is very explicitly NOT required and cannot be presumed. This is why ExternalMap is optional. In some cases, simply providing the ID could be adequate and desired.

SpdxDocument is currently the only method of recording information about the external element

This is true IF you wish to provide further contextal information beyond the ID of the external Elements but doing so is optional.