Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Keeping or not the filteringTerms.yaml inside every entry type folder #94

Open
costero-e opened this issue Jun 21, 2023 · 5 comments
Open

Comments

@costero-e
Copy link
Collaborator

costero-e commented Jun 21, 2023

First message of the issue #93, opening by @mbaudis.
I think the first point of the solution proposed here is the one I would adopt, deleting the filteringTerms.yaml files for each endpoint, as it is not strictly needed.

@redmitry
Copy link
Collaborator

deleting the filteringTerms.yaml

filteringTerms.yaml is a reference implementation thing.
The question is should we remove /filtering_terms endpoints from endpoints?


(or this was an error from the beginning?).

Will "filteringTermsUrl" in the /map have sense if there is a standard /filtering_terms endpoint?

D.

@mbaudis
Copy link
Member

mbaudis commented Jun 24, 2023

filteringTerms.yaml is a reference implementation thing.

Yes, no place in the model (as file).

The question is should we remove /filtering_terms endpoints from endpoints?

A) It shouldn't be there and we use scopes.
B) It should be there for all entyry types w/ "filters" option - but then we don't need scopes...

In any case the files don't make sense in the model.

@redmitry
Copy link
Collaborator

I'm for the "A".
the rationale:

  1. one single place for filters (simplifies things, especially in the BN).
  2. endpoints for entry types kept free from auxiliary stuff.

@costero-e
Copy link
Collaborator Author

I agree that if we add a multiscope field inside the filtering terms object, we can get rid of the specific filtering terms endpoints and just keep a general filtering terms endpoint. I will create a new branch for this feature this week to start working on this.

@jrambla
Copy link
Contributor

jrambla commented Oct 10, 2024

Addressed in PR #167 pending review

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants