Clarification on inputTypes key usage when the software supports any file type

[evilaliv3]

While working on the Globaleaks publication we are experiencing difficulties giving a value to the key inputTypes.

Similarly to a Content Management System (CMS), GlobaLeaks could manage every kind of file so that the current inputTypes seems to require us to list an unlimited set of mime types with significant inefficiency.

I suggest this key could be extended / documented clarifying how this condition should be handled.

[libremente]

Thanks @evilaliv3. We should definitely take a look at that key, any input (pun intended 😄) is appreciated!

[evilaliv3]

Thank you.

Actually i do not have useful suggestions and i think for ech key like this you need a boolean subkey like "SupportAny" to be set by default to false.

I think the final solution identified should be choosen considering similar issues like #95

[bfabio]

Moved to GitHub Discussions

_Why?

[bfabio]

I might be wrong, but i've always felt that {input,output}Types were influenced by Desktop files (genericName as well).

In general, that's a pretty desktop-centric key that is not really all that relevant besides for softwareType: standalone/desktop, and even for those applications brings a little value and is deemed not worth to keep updated. That's a guaranteed for incomplete information.

Case in point: not a single publiccode.yml in the Italian software catalog uses it.

IMO we should just deprecate it.

[libremente]

Totally agree @bfabio

[ruphy]

@bfabio I confirm, in the original design they were influenced by Desktop files and by the idea of helping administrations evaluate solutions which use open formats. Given the scarse usage by software vendors too, it might make sense to scrap it in a future release.
Are there thoughts from others?