CycloneDX 2.0 extensibleProperties example?

[nightlark]

Are there any examples of using the extensibleProperties field according to the draft CycloneDX 2.0 schema?

I maintain a tool that generates SBOMs, and currently we primarily use a custom SBOM format because the 1.x properties being limited to key-value pairs with values being strings is overly limiting. If CycloneDX 2.0 extensibleProperties enables capture information and attaching it to components in the form of data types other than strings (e.g. JSON objects, arrays, numbers, etc), we'd probably migrate away from using our custom format.

An example to illustrate what I'm hoping to achieve:

"components": [
  {
    "type": "library",
    "name": "example-lib",
    "version": "1.0.0",
    "purl": "pkg:npm/example-lib@1.0.0",
    "extensibleProperties": [
      {
        "ext:example.org:MyCustomTool": {
          "a_custom_number": 42,
          "some_bool": True,
          "nested object array": [
            {
              "okay": False
            }
          ]
        }
      }
    ]
  }
]

Is this roughly how extensible properties work, or does the schema within the extensible property need to be defined somewhere, like attaching a "mini" custom schema to every BOM that we generate?

[stevespringett]

Yes, that's how it would work. If the content of ext:example.org:MyCustomTool is an object, the $schema property also has to be supplied. Other than that, yes, that's how it would work. That way, tools could optionally validate the object.

[nightlark]

Is there a way to specify the $schema for a particular extensible property once in some top-level list of extensible property schemas? Just to avoid including a duplicate "$schema": "https://somewebsite.readthedocs.io/en/latest/schema/maybe.json" line 50,000 times in SBOMs with many components.