Discussion: How to handle extensions

[goneall]

This is a spin-off issue from #302 which discusses 2 issues focused on how to support Extension subclasses.

According to the SPDX AIPackage specification an optional property field is extension. This field is of type Extension.

Extension is an abstract class so it can't be instantiated.

Referencing an Extension in the JSON-LD without parameters passes the Java coded validation but fails the JSON schema validation (see related https://github.com/spdx/spdx-3-model/issues/1017):

"extension" : [
			{
				"type" : "extension_Extension"
			}
		]

Adding a parameter:

"extension" : [
			{
				"type" : "extension_Extension",
				"randomProperty" : "test"
			}
		]

causes the Java parser to fail with Analysis exception processing SPDX file: No property descriptor for field randomProperty.

Adding any additional type will also cause the Java code to fail.

Is there an approach where we can allow Extensions in the Java library?

[bact]

Note, the extension property is part of the Element class. So every subclasses inherit it. (Not specifically AIPackage).

[bact]

From the spec, I think to use Extension, one needs to define a concrete class to use it.

An SPDX validator may be expected to validate everything according to the standard SPDX schema but once it encounters the non-standard extension part - it will leave the validation of that part to the extension's validator (if any).

This means, if an SBOM uses a non-standard extension, it has to supply the extension schema too, if full validation is needed.

[goneall]

Discussing this on the implementers call with @pmonks - we could just store the JSON data for the extension property as a simple array of strings. We would leave it up to the caller of the library to deserialize the JSON string and utilize it.

It gets a bit more complicated if we want to handle the CdxPropertiesExtension which can be deserialized reliably.

I would propose that if we deserialize extensions and have a "type" : "extension_CdxPropertiesExtension", we handle it exactly as we do today.

For any other JSON value for extension, we store it in a new subclass of Extension that just stores the string value of the JSON.

This would make it easy to serialize / deserialize the Extension data reliably. However, it does move the work to interpret the extension data to the caller.

Specifically:

• A new Java class ExtensionJson will be introduced in the SPDX 3 model that has a single property json of type String. ExtensionJson would be a subclass of Extension.
• if the Element class has an extension array element with a "type" : "extension_CdxPropertiesExtension", it would be handled in the same manner as today
• for any JSON files that does not have a "type" : "extension_CdxPropertiesExtension", we create a ExtensionJson object and store the string value of the JSON.

For example, the serialization:

 "extension" : [
			{
				"type" : "extension_myOwnExtensionClass",
				"myExtensionProperty" : [
					{
						"type" : "myExtensionPropertytype",
						"myExtensionValue" : "This is a simple string value"
					}
				]
			}
		]

Would result in an ExtensionJson object being created and added to the collection of values for the Element extension property with the json property string value equal to:

{
				"type" : "extension_myOwnExtensionClass",
				"myExtensionProperty" : [
					{
						"type" : "myExtensionPropertytype",
						"myExtensionValue" : "This is a simple string value"
					}
				]
			}

[goneall]

Suggestion from tech call: Implement as a map of property name String to Object.