Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[2.0] refactor component for specificcomponent types

Open
#1,024 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Refactor
Clarity
Mostly clear
Activity status
Quiet
Tech stack
json
Domain
data

Research direction

Begin with the two linked specification pull requests and locate the current component definition. Trace how component references and type-specific requirements are used. Done means the component is split into base and type-specific definitions, the supported component types are represented by oneOf, and downstream property handling remains explicit.

Written by the indexing model from the issue text.

Description

CDX 2.0

after

the current component should be split in

  • baseComponent - core properties of a component
  • serviceComponent - inherit from baseComponent and add service-specific properties and requirements
  • softwareComponent - inherit from baseComponent and add {application,framework,library,...}-specific properties and requirements
  • hardwareComponent - inherit from baseComponent and add service-specific properties and requirements
  • fileComponent - inherit from baseComponent and add file-specific properties and requirements
  • dataComponent - inherit from baseComponent and add data-specific properties and requirements
  • ... and so on - for each component type

I would even put the baseComponent, serviceComponent, etc ... under /$defs/component/$defs/,
not under /$defs/

after that split, the current component becomes a oneOf ala

{
  "$defs": {
    "component" : {
      "oneOf": [
         {"$ref": "#$defs/component/$defs/serviceComponent"}
         {"$ref": "#$defs/component/$defs/hardwareComponent"},
         {"$ref": "#$defs/component/$defs/...Component"},
       ],

       "$defs": {
         "baseComponent": {
           "$comment": "This is a mixin. make sure to use `unevaluatedProperties` in the usage downstream"
           "type": "object",
           "required": [ ... ] 
           "properties": {
             "type": { "enum": ["service", "device", ...] }, 
             "bom-ref": ...,
             "parties": ...
             "group": ...,
             "name": ...,
             "description": ...,
             "version": ...,
             "versionRange": ..., 
             "isExternal": ..., 
             ...
             "components": { "$ref": "#$defs/components" }
           }
         },
         "serviceComponent": {
           "allOf": [{ "$ref": "#/$defs/component/$defs/baseComponent" }],
           "titile": "Service Component",
           "type": "object",
           "required": ["endpoint", ...]
           "properties": {
             "type": { "enum": ["service"] },
             // service-specific properties
             "endpoint": ...,
             "isExternal": { "default": true }, 
             ...
             "components": { "$comment": "opportunity: make all items requiring a certain `type`" }
           },
           "unevaluatedProperties": false
         },
         "...Component": { ... },
       } 
    }
  }


}
Dominant language
XSLT
Stars
551
Forks
93
Avg merge
4h 51m
Merged PRs (30d)
42

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from CycloneDX/specification

All issues in CycloneDX/specification

Similar issues

More Data Engineering issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.