[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?