Deprecate and define EOL/EOS path for XML

[stevespringett]

This issue is to discuss the possibility for eliminating support for XML

Currently, XML and JSON Schemas have some inconsistencies. Some of the inconsistencies are described in #146. There are many benefits to removing support for XML, including:

• Eliminate unnecessary complexity in libraries and tools supporting CycloneDX
• Reduce the number of dependencies needed in libraries/tools
• Decrease the amount of time needed by maintainers to keep libraries/tools up to date with current spec versions
• Decrease the probability of defects introduced in libraries/tools supporting CycloneDX
• Decrease the amount of time necessary for CycloneDX/Ecma standards development, review, and approval

If there is agreement by the CycloneDX Core Working Group and by Ecma TC54, we will need to define a deprecation path that leads to the eventual EOL/EOS for XML.

Community feedback necessary. Lets the comments commence...

[ppkarwasz]

At Apache Logging Services, we are publishing only the XML version of CycloneDX documents.

The reason behind this is that we can use a simple XSLT stylesheet (like this one) to overcome the limitation of the tools generating the SBOM (in our case cyclonedx-maven-pluging).

Sure, we could also move to some JSON technologies and tools.

[vy]

As @ppkarwasz indicated, at Apache Logging Services, in Maven-based projects, we fixed everything to XML, since the rest of the ecosystem is XML. Put another way, Maven speaks XML. That said, if needed, we can move our tooling to JSON.

Currently, XML and JSON Schemas have some inconsistencies. Some of the inconsistencies are described in https://github.com/CycloneDX/specification/issues/146. There are many benefits to removing support for XML, including:

@stevespringett, I am not able to follow the "there are some inconsistencies between XML and JSON schema, let's drop the XML support" reasoning. Such that, the listed arguments can very well be used to pitch for "drop JSON support in favor of XML". Could you help us understand what is the rationale behind choosing XML over JSON as the extra weight to drop?

[io7m]

I'd rather have the stability and rigour of XML.

It's been 13 years(!) and JSON Schema hasn't even shown any signs of being anything other than an endless series of "drafts".

[oej]

I am fine with leaving XML behind. Any issues with JSON has to be handled separately.

[stevespringett]

@vy

Could you help us understand what is the rationale behind choosing XML over JSON as the extra weight to drop?

Its based simply on demand. There are many tools that support CycloneDX, some of which support both XML & JSON, and others that only support JSON. We're seeing a lot more use of JSON over XML, so that is the only rationale behind favoring JSON over XML.

@io7m

It's been 13 years(!) and JSON Schema hasn't even shown any signs of being anything other than an endless series of "drafts".

I'm with you. My frustrations with JSON Schema are endless. Even simple things like providing a description for an enum cannot be done in JSON Schema, but can in XML Schema. So we have to overload the properties description with descriptions for each enum. It's a mess.

@oej I think most folks have a similar outlook of XML and JSON. Writing complex schemas in XML Schema is much more verbose than JSON Schema. Even with all the limitations of JSON, its a better developer experience IME.

[JDziurlaj]

We are using the XML version of the specification in order to be able to add extensions to the format via namespaced elements. We cannot do that with JSON in a strongly interoperable way.

[stevespringett]

@JDziurlaj Would CycloneDX properties allow you to capture the data you need without having to rely on XML namespaces?

[JDziurlaj]

We could make properties work for our current use case. We are exploring another use case for extending service definition which would almost certainly require the creation of structures beyond simple name/value pairs. We are generally XSLT/XProc users so we'd need to change our toolchain as well.

[jkowalleck]

i would love to keep XML a thing. data transformation is a use case i have from time to time, and using XSLT for it is very convinient.