CycloneDX / CycloneDX/specification

[CDX2.0]: have no "other" enums values where alternative, arbitrary strings are allowed

Open
#961 3 comments 0 reactions 0 assignees View on GitHub
CDX 2.0 defect
Dominant language
XSLT
Stars
547
Forks
93
Avg merge
4h 32m
Merged PRs (30d)
38

Description

## Describe the defect

CycloneDX 2.0 has enums for many things.
Some have the case "other".
And alternatively, same enum values are open, arbitrary string.

For example
- the new `persona` property - either an well-known (enums) value, or an arbitrary string.
**which was already fixed**
- AI ... `activity` - https://github.com/CycloneDX/specification/blob/bbbcaec713a9304e0ff2c1f83111434384393509/schema/2.0/model/cyclonedx-ai-modelcard-2.0.schema.json#L248-L258
- AI ... `energySource` - https://github.com/CycloneDX/specification/blob/bbbcaec713a9304e0ff2c1f83111434384393509/schema/2.0/model/cyclonedx-ai-modelcard-2.0.schema.json#L383-L395
- component ... `technique` - https://github.com/CycloneDX/specification/blob/bbbcaec713a9304e0ff2c1f83111434384393509/schema/2.0/model/cyclonedx-component-2.0.schema.json#L567-L578
- component ... `type` - https://github.com/CycloneDX/specification/blob/bbbcaec713a9304e0ff2c1f83111434384393509/schema/2.0/model/cyclonedx-component-2.0.schema.json#L631-L637
- many others on cryptography ...
- many others on license ...
- many others on vulnerability...
- to be continued

When the property can be either an enums or an arbitrary string, there is no need go an emum value "other".

## Goal

- Have no "other", when the enums is non-exclusive.
- At best, have them forward-compatible

## Additional context

Add any other context about the problem here.

## possible solution A

this is thing we are already using in other places.

- have it either a string - with enum values
- or have it an object with `name` and `description`

like here https://github.com/CycloneDX/specification/blob/2a860677bc58cc9accd7c8810eee1b4f29ce3343/schema/2.0/model/cyclonedx-party-2.0.schema.json#L496-L546

```json
{
"type": "object",
"properties": {
"foo": {
"oneOf": [
{
"title": "Pre-Defined Foo",
"type": "string",
"enum": [
"well-known-1",
"well-known-2",
"well-known-3"
],
"meta:enum": {
"well-known-1": "the description what this means",
"well-known-2": "the description what this other value means" ,
"well-known-3": "..."
}
},
{
"title": "Custom Foo",
"type": "object",
"required": [ "name" ],
"additionalProperties": false,
"properties": {
"name": {
"type": "string",
"minLength": 1,
"title": "Name",
"description": "The name of the custom foo."
},
"description": {
"type": "string",
"title": "Description",
"description": "A description of the custom foo."
}
}
}
]
}
}
}
```

## possible solution B

```json
{
"type": "object",
"properties": {
"foo": {
"type": "string",
"anyOf": [
{
"$comment": "well-known values",
"enum": [
"well-known-1",
"well-known-2",
"well-known-3"
],
"meta:enum": {
"well-known-1": "the description what this means",
"well-known-2": "the description what this other value means" ,
"well-known-3": "..."
}
},
{
"$comment": "custom value",
"type": "string",
"minLength": 1
}
]
}
}
}
```

Preferably,
we might even go with a prefix on the "custom"("other"), tho prevent collisions when adding new values with well-defined values

```json
{
"type": "object",
"properties": {
"foo": {
"type": "string",
"anyOf": [
{
"$comment": "well-known values",
"enum": [
"well-known-1",
"well-known-2",
"well-known-3"
],
"meta:enum": {
"well-known-1": "the description what this means",
"well-known-2": "the description what this other value means" ,
"well-known-3": "..."
}
},
{
"$comment": "custom - prefixed with 'custom: '",
"type": "string"
"pattern": "^custom: (.+)$"
}
]
}
}
}
```

## possible solution C

... to be discussed ...
maybe something like
```json
{
"type": "object",
"properties": {
"category": { "type": "string", "enum": ["red", "green", "blue", "custom"] },
"categoryCustom": { "type": "string", "minLength": 1 }
},
"required": ["category"],
"allOf": [
{
"if": { "properties": { "category": { "const": "custom" } }, "required": ["category"] },
"then": { "required": ["categoryCustom"] },
"else": { "not": { "required": ["categoryCustom"] } }
}
]
}
```

Contributor guide

Open the contributing guide

Research direction

Start with the referenced schema/2.0/model/cyclonedx-ai-modelcard-2.0.schema.json and schema/2.0/model/cyclonedx-component-2.0.schema.json locations, then review the analogous party schema pattern. Identify every non-exclusive enum that still includes "other" across the listed AI, component, cryptography, license, and vulnerability areas; done requires an agreed forward-compatible representation and consistent schema changes.

Written by the indexing model from the issue text.

Assessment

Tech stack
json
Domain
backend-api-design
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Needs clarification
Newbie friendliness
42/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.