-
Notifications
You must be signed in to change notification settings - Fork 0
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
Update spec: return errors as Objects – (and a 'Not Implemented' code?) #11
Comments
|
|
Yes, the spec would benefit if that were written into it:
I'm not convinced we need to require the use particular error Strings. Because that would mean that we take a responsibility to define many more possible error codes, over time. But we have no use-case for it (i.e. to make it machine-interpretable). I think that modules that call a vsm-dictionary's code simply have to account for the fact that a truthy
|
Not all real-world APIs support some of the operations requested by
getDictInfos
orgetEntries
for example.Usually this issue had to do with asking more general information from the APIs - e.g. asking for all dictionary information, all entries (in all possible sub-dictionaries/ontologies).
Thus, the specification should include information on what object should these functions return in these cases.
E.g., it could be something like:
The text was updated successfully, but these errors were encountered: