Dependencies within Dependency class should be List<String> not List<Dependency>

[ajbrown]

the Dependency class currently contains a dependencies field which is typed as a List<Dependency>, which implies that dependencies can be nested. This is incorrect based on both the current specification and the JSON schema, which has "dependsOn" as a list of bom-refs. This can lead to developers believing dependencies can be nested, and producing invalid BOMs as a result.

To double check this, I also compared this with the JavaScript which does implement the dependencies list as a string.

[stevespringett]

I'd have to check the spec, but I believe this exists due to the XSD definition of dependency, which can contain another dependency.

[ajbrown]

Hi Steve!

It does in fact seem that the XSD allows nested dependency objects https://github.com/CycloneDX/specification/blob/c3da323e637e4fbe770126ce3359faa9770f8743/schema/bom-1.4.xsd#L1187-L1202

    <xs:complexType name="dependencyType">
        <xs:sequence minOccurs="0" maxOccurs="unbounded">
            <xs:element name="dependency" type="bom:dependencyType"/>
        </xs:sequence>
        <xs:attribute name="ref" type="bom:refType" use="required">
            <xs:annotation>
                <xs:documentation>References a component or service by the its bom-ref attribute</xs:documentation>
            </xs:annotation>
        </xs:attribute>
        <xs:anyAttribute namespace="##other" processContents="lax">
            <xs:annotation>
                <xs:documentation>User-defined attributes may be used on this element as long as they
                    do not have the same name as an existing attribute used by the schema.</xs:documentation>
            </xs:annotation>
        </xs:anyAttribute>
    </xs:complexType>

however, If I'm reading this correctly that's conflicting with the JSON schema and the published documentation (which I now assume is auto generated from the JSON schema?).

https://github.com/CycloneDX/specification/blob/master/schema/bom-1.4.schema.json#L895-L920

"dependency": {
      "type": "object",
      "title": "Dependency",
      "description": "Defines the direct dependencies of a component. Components that do not have their own dependencies MUST be declared as empty elements within the graph. Components that are not represented in the dependency graph MAY have unknown dependencies. It is RECOMMENDED that implementations assume this to be opaque and not an indicator of a component being dependency-free.",
      "required": [
        "ref"
      ],
      "additionalProperties": false,
      "properties": {
        "ref": {
          "$ref": "#/definitions/refType",
          "title": "Reference",
          "description": "References a component by the components bom-ref attribute"
        },
        "dependsOn": {
          "type": "array",
          "uniqueItems": true,
          "additionalItems": false,
          "items": {
            "$ref": "#/definitions/refType"
          },
          "title": "Depends On",
          "description": "The bom-ref identifiers of the components that are dependencies of this dependency object."
        }
      }
    },

Perhaps this needs a sister issue on the schema project to figure out which one is true. Depending on which is correct, some of the language libraries will need to be adjusted. I will go ahead and open an issue there, referencing this and the other ticket I opened.

[stevespringett]

Thanks. I think both are true. I think we have close to 95% parity between XML and JSON in terms of its representation. This is one area where the two serialization formats differ. There are a few others.

[ajbrown]

I think both are true.

As in, it should be either a string OR an object? I believe at the moment there are portability issues between Java and JavaScript. I'll be able to test that here shortly.