[Development] Support for *Notes and UpstreamFiles fields in qt_attributions.json files

[Hasselmann Mathias]

Hi,

Just to make ensure all options are considered: How about the elephant 
in the room?
How about "simply" implementing JSONC (JSON with Comments) in Qt's JSON 
parser instead?

* People wonder regularly when they learnm that there are no comments in 
JSON.
* JSONC is used by popular software like VSCode and TypeScript.
* The runtime parsers of PowerShell, .NET, and probably others already 
support
   it out of the box. For JavaScript and Python there are drop-in libraries.
* A MIT licensed implementation with examples and tests can be found here:
   https://github.com/Microsoft/node-jsonc-parser

Ciao
Mathias

Am 16.02.2023 um 10:57 schrieb Edward Welbourne via Development:
> Kai Köhne (15 February 2023 08:50) replied:
>>>> Well, you can also achieve this by duplicating comment fields:
>>>>
>>>> {
>>>>    "Comment": "Upstream files are src/x.cpp, include/y.h",
>>>>    "Files": [ "x.cpp", "y_p.h"]
>>>>    "Comment": "Copyright info is from dist/COPYING",
>>>>    "Copyright": "Copyright (C) 2023 Joe Doe"
>>>> }
> Edward Welbourne (Wednesday, February 15, 2023 10:45 AM) objected:
>>> The problem with that is that I was given to understand that
>>> duplicated keys is actually malformed JSON - perhaps I misunderstood.
>>> If that's legitimate JSON, then I'm fine with just one.
> and, overlapping with my follow-up correcting that,
> Kai Köhne (15 February 2023 17:10) replied:
>
>> To my understanding it's valid JSON, at least from the syntax
>> side. From
>> https://www.ecma-international.org/publications-and-standards/standards/ecma-404/
>> :
>>   The JSON syntax does not impose any restrictions on the strings used
>>   as names, *does not require that name strings be unique*, and does
>>   not assign any significance to the ordering of name/value
>>   pairs. These are all semantic considerations that may be defined by
>>   JSON processors or in specifications defining specific uses of JSON
>>   for data interchange
> It seems we read the same standard at about the same time, arriving at
> the same conclusion ;^>
>
>> And the JSON parsers I tested (Python, Qt) don't treat it as an error,
>> either. There seems to be some online linters like
>> https://jsonlint.com/ that complain about it, tough.
> I think we can live with ignoring a warning from linters that aren't
> part of our tool-chain ;^>
>
> I've updated my reviews to the "Comment" version.
>
> That just leaves us with the open question of whether to, instead,
> switch to some other way of storing the data - preferably one that
> supports multi-line strings - with Ulf currently championing QML and
> Thiago YAML.
>
> 	Eddy.