received filters in summary to object

[redmitry]

There is an incoherence formats of filters submitted to the query and reported to be submitted:

"request summary" vs "submitted".

This pull request is to use the same filteringTerms format (object) in the beaconReceivedRequestSummary.

N.B. This would change 2.0 spec.

D.

[mbaudis]

As per our discussion I'm +1 on this. However, branch management => into develop, IMO? @costero-e ? Therefore no formal approval right now.

Note to @redmitry: You also restructure the FilteringTerms document - while this shouldn't break anything (not sure about the $ref inlining; rusty on JSON Schema...) I usually would make this at least a different commit.

[costero-e]

@redmitry Why is the "id" inside brackets array? Is it because the term can apply to different scopes so you have to define it for each of the scope differently?
Answering to @mbaudis about the branch it should be merged to, if it is not a hotfix, this should be developed in a feature branch (new branch) and then make a PR to develop, indeed.

[redmitry]

@redmitry Why is the "id" inside brackets array? Is it because the term can apply to different scopes so you have to define it for each of the scope differently?

Do not get it. The only "id" inside brackets is in "required"

"required": [
                "id"
            ],

e.g.

beacon-v2/framework/json/common/filteringTerms.json

Line 60 in 753d12f

"id"

D.

[costero-e]

Hey @redmitry, I meant in the examples:

"examples": [ "demographic.ethnicity:asian" ],

This would be passed as an "id" in the request but here you are specifying it has to be inside an array?

Edit: Ah, now I see is type: "string", I said nothing, sorry.

[redmitry]

Hey @redmitry, I meant in the examples:

"examples": [ "demographic.ethnicity:asian" ],

Ah! Got it.

Json Schema spec. >= draft-6
introduced standard "examples" tag to provide examples as an array of strings. We have to replace all non nomenclature "example": "" with standard "examples" : [""].

[costero-e]

I changed the base branch to "develop". The rest seems fine so this is approved on my side.

[jrambla]

I understand your point, @redmitry . However the difference between request and summary is there on purpose (not a strong purpose, I must say, anyway).
The request SHOULD, of course, have a detailed description of the filter to apply, and hence the syntax must be comprehensive.
The current receivedRequestSummary, however, was not meant for machine processing, but for human inspection in case it is necessary.
This decision design is not necessarily correct and making it machine readable could be beneficial (how much? for which use case?).
However, if the PR is breaking the 2.0 specification, we SHOULD NOT added it now, but in a future release.