[Defect]: Inconsistency of formats: can data in data components be repeated?

[andreas-hilti]

Describe the defect

In JSON, the data member of a (data) component is an array: https://cyclonedx.org/docs/1.6/json/#components_items_data In protobuf, it is not repeated: https://github.com/CycloneDX/specification/blob/bfb6f8baf77bbf98a4c0a54392508ba3ccf2e22e/schema/bom-1.6.proto#L142-L143

Also in xml it is not repeated: https://github.com/CycloneDX/specification/blob/bfb6f8baf77bbf98a4c0a54392508ba3ccf2e22e/schema/bom-1.6.xsd#L701-L706

for instance this is not valid:

<?xml version="1.0"?>
<bom serialNumber="urn:uuid:44dabf30-74d9-4949-9bef-1da4ef41a531" version="1" xmlns="http://cyclonedx.org/schema/bom/1.5">
	<components>
		<component type="data">
			<name>acme-library data</name>
			<data>
				<type>source-code</type>				
				<contents>
					<url>http://acme.org/src</url>					
				</contents>
				<classification>public</classification>
			</data>			
			<data>
				<type>other</type>				
				<description>Description of other data</description>
			</data>			
		</component>
	</components>
</bom>

Additional context

• Based on this discussion: https://cyclonedx.slack.com/archives/CV062H2GH/p1725377607293819
• I believe that the intention was that it is repeated, but I'm not 100% sure.
• Is there a similar issue for services > data?

[stevespringett]

Thanks for reporting. Looks like a defect in the XML Schema. The correct fix should be to make maxOccurs unbounded.

[jkowalleck]

changing the current ProtoBuff item from optional to repeated would be a breaking change in the implementation

[andreas-hilti]

changing the current ProtoBuff item from optional to repeated would be a breaking change in the implementation

Why is this? Is proto2 supported as well?

For proto3: https://protobuf.dev/programming-guides/proto3/#updating

For string, bytes, and message fields, optional is compatible with repeated. Given serialized data of a repeated field as input, clients that expect this field to be optional will take the last input value if it’s a primitive type field or merge all input elements if it’s a message type field.

Unless I'm mistaken, all messages that contained only a single "data" would continue to work, and this is the kind of compatibility that you are looking for, isn't it?

[jkowalleck]

For string, bytes, and message fields, optional is compatible with repeated. [...]

the field in question is a complex type - a message. so there should be no issue fixing this, I guess.

@nscuro what do you think?

---

the XML could be fixed in an upcoming dot release, too. the proto buff - I will clarify anc check.

@stevespringett,

i would pull this fix into the upcoming 1.6.1 if this is okay.

[stevespringett]

1.6.1 is ok @jkowalleck

[jkowalleck]

@andreas-hilti ,

may I ask you for a code review of the proposed fix? https://github.com/CycloneDX/specification/pull/530