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

[Edward Welbourne]

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.