-
Notifications
You must be signed in to change notification settings - Fork 37
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
Need to define "recognized" database prefix #413
Comments
I consider recognized prefixes to be those prefixes that are defined in providers.json under the "id" field. |
Right, which is indeed precisely not what this term has been used for in the specification :-), hence the need to clarify/change that term. So, what would you consider a good term for a prefix that is so familiar to your implementation that you are prepared to validate what prefixed fields are available, etc.? We could of course just allow this for the implementation's "own prefix", however, we've been moving in the direction of namespaces - and some tool prefixes (e.g., |
How about "supported prefixes" ? |
We discussed this on the web meeting Sept 28, 2022. We probably should address this simultaneously with decoupling the prefix list and providers. (If we should that, seems to be a bit of different opinions.) |
In discussion of #376 we realized we already use the term "recognized" database prefix already in the specification, and it is not very clear.
We believe it means a prefix for which your impementation knows precisely which prefixed fields are defined.
PR #376 adds "recognized database prefix" in a place to mean this, but will not attempt to fix the issue.
The text was updated successfully, but these errors were encountered: