xml/json 1.5 spec differences?

[divagant-martian]

Comparing the two specification I've found a couple differences.

json definitions

Last one is about Dependency
in json it is defined as having two properties: ref and dependsOn, the first a refLinkType, second one a list of refLinkType

where refLinkType is defined in terms of refType. Both definitions are here:

specification/schema/bom-1.5.schema.json

Lines 123 to 132 in 8e131b1

	"refType": {
	"description": "Identifier for referable and therefore interlink-able elements.",
	"type": "string",
	"minLength": 1,
	"$comment": "value SHOULD not start with the BOM-Link intro 'urn:cdx:'"
	},
	"refLinkType": {
	"description": "Descriptor for an element identified by the attribute 'bom-ref' in the same BOM document.\nIn contrast to `bomLinkElementType`.",
	"allOf": [{"$ref": "#/definitions/refType"}]
	},

specification/schema/bom-1.5.schema.json

Lines 1224 to 1248 in 8e131b1

	"dependency": {
	"type": "object",
	"title": "Dependency",
	"description": "Defines the direct dependencies of a component or service. Components or services that do not have their own dependencies MUST be declared as empty elements within the graph. Components or services 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 object being dependency-free. It is RECOMMENDED to leverage compositions to indicate unknown dependency graphs.",
	"required": [
	"ref"
	],
	"additionalProperties": false,
	"properties": {
	"ref": {
	"$ref": "#/definitions/refLinkType",
	"title": "Reference",
	"description": "References a component or service by its bom-ref attribute"
	},
	"dependsOn": {
	"type": "array",
	"uniqueItems": true,
	"items": {
	"$ref": "#/definitions/refLinkType"
	},
	"title": "Depends On",
	"description": "The bom-ref identifiers of the components or services that are dependencies of this dependency object."
	}
	}
	},

so dependsOn, in simple terms is a list of String

---

xml definitions

Here are the same definitions in xml:

refLinkType and refType look the same to me:

specification/schema/bom-1.5.xsd

Lines 38 to 55 in 8e131b1

	<xs:simpleType name="refType">
	<xs:annotation>
	<xs:documentation>Identifier for referable and therefore interlink-able elements.</xs:documentation>
	</xs:annotation>
	<xs:restriction base="xs:string">
	<xs:minLength value="1"/>
	<!-- value SHOULD not start with the BOM-Link intro "urn:cdx:" -->
	</xs:restriction>
	</xs:simpleType>
	<xs:simpleType name="refLinkType">
	<xs:annotation>
	<xs:documentation xml:lang="en">
	Descriptor for an element identified by the attribute "bom-ref" in the same BOM document.
	In contrast to `bomLinkElementType`.
	</xs:documentation>
	</xs:annotation>
	<xs:restriction base="bom:refType"/>
	</xs:simpleType>

but dependencies is defined as a sequence of dependencyType elements:

specification/schema/bom-1.5.xsd

Lines 1783 to 1798 in 8e131b1

	<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:refLinkType" use="required">
	<xs:annotation>
	<xs:documentation>References a component or service by 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>

so it's a recursive type, in comparison to a list of Strings in json. Beside the simplification of String vs reftype etc, this makes it so that a dependency tree of multiple levels, say 3, it's invalid in json but valid in xml.

---

valid dependencies according to the test resources

Here there is a "valid xml dependency" according to the test resources:

specification/tools/src/test/resources/1.5/valid-compositions-1.5.xml

Lines 28 to 33 in 8e131b1

	<dependencies>
	<dependency ref="acme-application-1.0">
	<dependency ref="pkg:maven/partner/shaded-library@1.0"/>
	<dependency ref="pkg:maven/acme/library@3.0"/>
	</dependency>
	</dependencies>

Note that the top dependency's children both are declared as dependency and have a ref attribute.

On the other side, the "valid json dependency" here

specification/tools/src/test/resources/1.5/valid-dependency-1.5.json

Lines 26 to 37 in 8e131b1

	"dependencies": [
	{
	"ref": "library-a",
	"dependsOn": []
	},
	{
	"ref": "library-b",
	"dependsOn": [
	"library-c"
	]
	}
	]

contains a dependsOn element "library-c" which clearly is not a dependency highlighted by the lack the required ref property. Taking into account that json schema supports recursion in arrays it looks to me like this could have been modeled the same way as the xml counterpart. Just to be sure, I tried an online json schema validator using what I would expect to get here

I've encountered multiple discrepancies between the specifications, fields that are attachment in one and textattachments in other, types that have one single field in one but two in other, etc.

This leaves me wondering.. are they not supposed to match? If not, should this be documented somewhere? What are the consequences of having a same bom that serialized in json and xml convey different information?

[jkowalleck]

Comparing the two specification I've found a couple differences.

JSON and XML do have different scopes and capabilities - technical wise. They are not the same, and therefore they have different capabilities and different solutions to the same problem.
Therefore, the CycloneDX schema for JSON and XML are not the same, but they are a practical representation of the CycloneDX specification.
The data models are more than just some types and structures, they have meaning/semantics stated in the element descriptions/annotations.

---

I tried to understand your concerns, but was not able to process your remarks and find any entry-point. Do you need further documentation? Do you want to propose an improvement? I don't understand.
Sorry, could you condense your remarks to concrete questions?

[divagant-martian]

Thanks, as stated:

should this be documented somewhere? What are the consequences of having a same bom that serialized in json and xml convey different information?

The simple answer of "yes they are different" is worrisome from the perspective of an implementer since we were under the impression this is one standard but from a technical point of view this requires the modeling and validation of two different ones without any apparent reason. This is even more unexpected when what's modeled in XML is clearly achievable in Json as well but it's simply not done this way.

Let's begin with this specific discrepancy. Why is the dependency modeled differently in XML and Json when there is no limitation coming from the Json schema requiring this. Is this decision documented somewhere?

[jkowalleck]

we were under the impression this is one standard

This is still true.

CycloneDX is a standard.
The standard is implemented in several target formats: XML/XSD, JSON/JsonSchema, ProtoBuff.