BC: Address problems with v1.5 introducing arrays where items are "oneOf"different types

[mrutkows]

There are issues creating libraries/tools that implement as you need to do quite a bit of additional reflection to determine which "item" datatype to use. This problem is compound where one item is a primitive (e.g., string) and another an object (struct).

I plan to update this issue with all the cases that are (especially) problematic.

• "environmentVars": mixing a string type with an object type is esp. problematic in coding implementations as not concrete structures (work around using structure that aggregates all fields from both types) can be created and code always must use reflection to determine which is cumbersome.

"environmentVars": {
          "title": "Environment variables",
          "description": "Inputs that have the form of parameters with names and values.",
          "type": "array",
          "uniqueItems": true,
          "items": {
            "oneOf": [
              {
                "$ref": "#/definitions/property"
              },
              {
                "type": "string"
              }
            ]
          }

• "serviceData": mixing 2 named type. Thankfully, both resolve to "string" for now; however, the "bomLinkElementType" if changed to an "object" could cause typeing problems in impls.

   "source": {
          "type": "array",
          "items": {
            "anyOf": [
              {
                "title": "URL",
                "type": "string",
                "format": "iri-reference"
              },
              {
                "title": "BOM-Link Element",
                "$ref": "#/definitions/bomLinkElementType"
              }
            ]
          },

---

Another issue concerns as "legacy" objects can be removed; however, again we have an array of object vs. a single object with arrays in it.

• Tools: One of
  • (single object) Creation Tools
  • despite allowing arrays (and links/refs) fully including all fields of "component" and/or "service" seems like overkill
  • (array of object) Creation Tools (legacy)
  • remove "legacy"

[jkowalleck]

[...] environmentVars [...]

this is the same as #249, right?

PS: #249's goal is to make environmentVars a dictionary, removing the option for a string entirely.

---

[...] source [...]

this should be no issue. it is an array of iri-reference. You will see that #/definitions/bomLinkElementType references also iri-reference, but with a regex. So the type is either a iri-reference or a special iri-reference -- so both are iri-reference, right?

however, the "bomLinkElementType" if changed to an "object" could cause typeing problems in impls.

i do not see an object. could you point me to it?

[mrutkows]

@jkowalleck This adds a new perspective/concern in addition to #249

[mrutkows]

this should be no issue. it is an array of iri-reference. You will see that #/definitions/bomLinkElementType references also iri-reference, but with a regex. So the type is either a iri-reference or a special iri-reference -- so both are iri-reference, right?

I acknowledged that both map to "string" now, however, since they are now both named types (definitions) and could easily be turned into "objects" with multiple fields which would cause similar issues.

[jkowalleck]

I acknowledged that both map to "string" now, however, since they are now both named types (definitions) and could easily be turned into "objects" with multiple fields which would cause similar issues.

I do not see any issues NOW nor is there a change for issues in the future. I'd suggest we clarify this in one of the upcoming meetings.

PS: all your concerns would be breaking changes anyway, so I don't see a reason for discussion. Nobody intended to change some "string" to "object". it is just not happening, no matter if "named types" or not ...

[dn-scribe]

Hi, Not sure this is the right place - please redirect me if not.

Wanted to note that there is already an ecosystem of tools that are starting to break due to these "breaking changes"; Take for exmple the Tools section. Syft producse the 1.5-introduced object:

    "metadata": {
        "timestamp": "2024-01-21T08:54:33+02:00",
        "tools": {
            "components": [
                {
                    "type": "application",
                    "author": "anchore",
                    "name": "syft",
                    "version": "0.100.0"
                }
            ]
        },

But tirvy fails on the decoding:

2024-01-21T08:56:33.671+0200    FATAL   sbom scan error: scan error: scan failed: failed analysis: SBOM decode error: failed to decode: CycloneDX decode error: CycloneDX decode error: json: cannot unmarshal object into Go struct field Metadata.metadata.tools of type []cyclonedx.Tool

I recommend trying super-hard to enable backward compatibility.

[jkowalleck]

re: https://github.com/CycloneDX/specification/issues/270#issuecomment-1902537330 @dn-scribe please open an extra issue for your topic. I will hide your post here, as it is off-topic.

PS: the discussion from https://github.com/CycloneDX/specification/issues/270#issuecomment-1902537330 was continued in https://github.com/CycloneDX/specification/issues/364