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.

[jrambla]

We need to review this PR as it seems to have some dependencies or conflicts

This can't be merged anymore.

[costero-e]

We need to review this PR as it seems to have some dependencies or conflicts

Exactly, this can't be merged anymore and we should restart PR from another branch that comes from the updated develop branch.

[gsfk]

Can we get this or something similar merged soon?

• If there are worries about breaking changes can we not simply make filters in receivedRequestSummary follow either the current definition (string) or the the spec at filteringTerms.yaml (object), and mark the old definition as deprecated?

• If this field is meant for humans, then doesn't it make sense for it to match the filters in the request exactly, rather than converting to a different type?

• The spec says nothing about how you should go about representing an object as a string, so implementations vary widely. Looking at existing beacons, I see

  "filters": ["sex=female"]

  "filters": ["sex", "=", "female"]

  and just wrapping the filters in a json serializer will get you this, which neither machines nor humans will like:

  "filters": [ "{\"id\": \"sex\", \"operator\": \"=\", \"value\": \"female\"}"]

[redmitry]

• The spec says nothing about how you should go about representing an object as a string, so implementations vary widely. Looking at existing beacons, I see
  "filters": ["sex=female"]

This is how reference implementation does and I also stick with.

Can we get this or something similar merged soon?

Personally, in a context of logical filters, I would change the spec to just a string:
"filters": "NCIT:C20197 & (!Weight | BMI)" (eq requested "filtersLogic")
So when there is no "filtersLogic" provided in the request, this would be "AND", so instead of
"filters": ["sex=female", "age>65"], we would have (default "AND") "filters": "sex=female & age>65".
When "filtersLogic" is provided "filters" will be equal to it.

Cheers,

D.