-
Couldn't load subscription status.
- Fork 355
Description
While designing the UI to download reports from ORT Server, the topic came up what an appropriate grouping of reports could be. Currently, the ORT Server only has "SBOMs" and "Other" groups, but this categorization could be more fine-granular, and provide more information about the intended use or target audience.
Thus the idea came up to introduce a dedicated ReporterType enum. As reporters are plugins and we'll never be able to offer proper types for all (third-party) reports, there certainly needs to be an OTHER enum entry. But what else should we have to start with? (We can always add more distinct types later.)
The current proposal would be
enum class ReportType {
// Standardized SBOM formats.
// Examples: CycloneDX, SPDX.
SBOM,
// Any attribution document.
// Examples: NOTICE.
ATTRIBUTION,
// Reports that serve as input to third-party applications or that are generated by a third party.
// Examples: AOSD, Ctrl-X, EvaluatedModel, FossID, OpossumUI, TrustSource.
MACHINE_READABLE, // or INTEROPERABILITY?
// Reports that are not meant for distribution.
// Examples: StaticHTML, WebApp.
VISUAL, // or OVERVIEW, TECHNICAL, STATISTICS?
// Anything that does not generally fall under the above.
// Examples: All AsciiDoc template reporters.
OTHER // or GENERIC?
}(I believe to have captured all our current reports in the above categorization.)