Introduce dedicated types for reporters

[sschuberth]

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.)

[fviernau]

This to me seems purely a UI requirement in ORT server, and may change.
Should this ticket be moved to ORT server, to not have code in ORT which is purely about how some code using ORT is grouping things in a UI? This would be much easier to improve on the UI side.

[sschuberth]

This to me seems purely a UI requirement in ORT server, and may change.

While triggered by ORT Server related UI questions, I also see value for the ORT CLI (which also is a UI) in this feature. For example, ort report --help could list the type of report next to their names, giving the user more guidance about the report to choose.

This would be much easier to improve on the UI side.

I disagree here. The type of a report is an inherent feature of the report itself. Any UI (CLI and ORT Server) should use the same type for a report, because a specific report format knows best what type it is. As such, the type should be implemented as part of the reporter API in ORT (core).

[mnonnenmacher]

This would be much easier to improve on the UI side.

The problem with this are custom plugins and template reports where the type cannot be known ahead of time. The latter is a challenge for the implementation because it requires a way to set the type of the report when generating it, maybe from within the template, and to make it available programmatically, so that the CLI or any other tool like the server can show it.

[fviernau]

The problem with this are custom plugins and template reports where the type cannot be known ahead of time. The latter is a challenge for the implementation because it requires a way to set the type of the report when generating it, maybe from within the template, and to make it available programmatically, so that the CLI or any other tool like the server can show it.

Hm, I still believe how ORT server's UI groups things is out-of-scope of the ORT project.
Also a plugin custom implementation might not want to care about that.

Would it make sense to do this with a labeling mechanism? key-value-pairs associated with plugins, which ORT does not know how to interpret. Such as ort-server-report-category:spdx? This way, categorization can be defined in ORT server, and changed in ORT server. And plugins which want to configure that could simply hard-code that.

If such labels could be additionally (to the hard-coding) be configured in ort/config/config.yml , then users could even adjust it.

[sschuberth]

Hm, I still believe how ORT server's UI groups things is out-of-scope of the ORT project.

What about

For example, ort report --help could list the type of report next to their names, giving the user more guidance about the report to choose.

[tsteenbe]

Not liking INTERNAL_USE enum as WebApp and EvaluatedModel are shared between parties (know 3 users that share them external) and several tools use EvaluatedModel as input such as Hermine project see their Uploading a BOM file doc.

[sschuberth]

Not liking INTERNAL_USE enum

Then please make constructive proposals for other names.