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

[goneall]

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:

• An Element requires a creationInfo property
• CreationInfo requires one or more Agents which are a type of Element
• 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
• SpdxDocument is the preferred method of pointing to the root of the serialized graph (although there are other methods such as a Bundle)
• You can use an external element for the Agent, but to do so you would want to record information about the external element
• SpdxDocument is currently the only method of recording information about the external element

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]

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.

[goneall]

@sbarnum - I also recall the discussions and agree we reached an agreement to allow non-document exchanges.

The reason I wrote the above is from practical experience attempted to implement what we agreed to and finding it not feasible for the situation of individual licenses.

From reading the above, it looks like the only situation where you would not need to wrap an element with an SPDX document is if you are communicating a single Agent with a creation info with the created ONLY having the same Agent you are communicating. This is due to the need to reference external elements and the mechanisms we used to communicate that is in SPDX documents. Yes - it is optional in the spec, but if you want to be able to validate the external elements it is a requirement.

Can you think of another example which would work if I had a requirement to validate the external element reference?

In terms of streaming, you could stream an SPDX document or a series of SPDX documents even if they only contain a single element.