We also run into that issue, trivy inherits this issue :/

Hi everyone!
I'm working on this task.
Can you assign it to me?

I'll try to finish it today or next week.

Created #204

Just my thoughts as a user of the library, regarding @DmitriyLewen's approach:

• Existing code using the Identity field will need to be refactored
• If the Identity field is populated, marshalling will only create CycloneDX 1.6 compliant files, which, depending on the case, may not be desired (OK, I know this is explicitly mentioned in the readme)
• The logic for decoding and converting between versions is getting increasingly complex

@nscuro Perhaps it could make sense to consider introducing different BOM structures for different versions (or range of versions) of the specification, with the possibility of explicitly converting one to the other (most likely from a version to the next one).
Of course, this means some duplication in the structure definitions, but overall I think it would make the implementation and the use of the library clearer:

• No breaking changes: the user chooses the version of structure to use and has a well defined upgrade path if needed
• No workarounds in the JSON/XML decoders
• All logic to convert between versions would be in clearly defined, separate conversion functions (JSON/XML agnostic) with clear semantics
• Overall, it would be more straightforward for both maintainers and users to support newer CycloneDX versions in the future

One of our use cases (probably a typical one) is decoding an external JSON/XML file, which might be of any version, and use it via a specific version of the structure (which may or may not be the latest). To support this, there could be a helper function which decodes the file to the correct structure, matching the file version (e.g. extracted with gjson), and then converts it using the conversion functions, possibly multiple times, until the version wanted by the user is reached.

Note that a similar approach has been taken for SPDX files: https://github.com/spdx/tools-golang

I agree with your thoughts @darioandre.
Your solution seems more correct.

But this problem exists now. We have a problem - users can't scan the CycloneDX file (aquasecurity/trivy#6902 (comment)), so we want to fix this problem as soon as possible.

see also: #207