spdx
JSON to XML conversion: Hyphen in 'PACKAGE-MANAGER' replaced with Underscore
"PACKAGE-MANAGER" string used in External Reference field is converted from JSON format to XML/YAML format, and '-' is converted to '_'. https://spdx.github.io/spdx-spec/v2.3/package-information/#721-external-reference-field
This means the current version is not conformant with the spdx 2.3 standard, right?
From what i see, this could be solved by replacing _ with - for the category name in here: https://github.com/spdx/tools-python/blob/8dc336f783e993d7e347d20b8ecd50b8808abf70/src/spdx_tools/spdx/jsonschema/external_package_ref_converter.py#L21
This is a common issue that keeps popping up (see #813), but this is an issue with the spec as you can see in this discussion https://github.com/spdx/spdx-spec/issues/792, not with the tooling. The spec only specifies the dash for tag value output which is also what the tooling writes, for JSON/YAML/XML the spec also allows underscore, we decided to support both (underscore and hyphen) when parsing data from JSON/YAML/XML but only write one, i.e., underscores with our tooling.
In the #792 discussions it is also mentioned that the spec is now only containing dash (https://github.com/spdx/spdx-spec/commit/214f23d34ee287cb1db5b31c3d571af291e836f3). This means that if people go strictly after the schema, the produced sbom is invalid. So basically every tool along the way has to implement the bugfix in order to read this sbom. The fix would make it compliant to the scheme.
My understanding of the discussion is that the "only dash spec" was a bug in the spec and both options should be valid. However for v2.2 only the underscore was valid (https://github.com/spdx/spdx-spec/blob/development/v2.2/schemas/spdx-schema.json) and as this tooling should support as much as possible using the underscore is a valid choice. I am still not convinced that this needs to be fixed as also the discussions state that tooling should support both versions when parsing data (https://github.com/spdx/spdx-spec/issues/792#issuecomment-1268687083).