Response meta can't handle many filtering terms

[gsfk]

Looking again at the response meta (see #55), it includes a receivedRequestSummary field that uses its own definition of filters that's not used anywhere else:

framework/src/common/beaconCommonComponents.yaml#/definitions/Filters:

Filters:
    description: >-
      Ontology based filters. A CURIE syntax is encouraged to be used.
    type: array
    items:
      type: string
    example:
      - BTO:0000199
      - PATO:0000383

This requires filters to be strings, when two of the three kinds of filtering terms are objects, not strings. I can flatten to string in the response of course, but this is not that useful and will be ugly (e.g. I may have to escape double quotes in the object).

Shouldn't this definition point somewhere else, for example framework/src/requests/filteringTerms.yaml ?

[redmitry]

This is a very old story... 🤷
#107

Dmitry

[gsfk]

huh, thanks... I didn't think to look in prs for this issue.