bibliographyEndpoint could be more tolerant
Created by: pchampin
Currently, if the data sent to the bibliography endpoint contains one bad easyKey (either ambiguous or unmatched), the result is a 400 error.
Wouldn'it be better to get a 2XX response, with all the data for the good easyKeys, and an indication that some inputs were broken ? Note that 2XX could be ≠ 200, so that errors can be easily spotted ?
My use case is the following: in a Sphinx document (using zot4rst), if a single reference is broken in my document, no reference at all is displayed...
Imported comments:
By egh on 2015-01-31 21:19:07+00:00
This is easy enough to implement on the zotxt side, but I'm not sure how the error reporting would work in sphinx.
By pchampin on 2015-02-12 13:36:19+00:00
I would expect that this situation issue a warning in the sphinx output, and that broken reference are replaced by a distinctive text to be easily spotted... Note that this is a user's point of view, I'm not sure how to do that in sphinx exactly...
By mcepl on 2015-09-11 20:57:13+00:00
I think 2## is a wrong status code (“2xx: Success - The action was successfully received, understood, and accepted” from IANA website). I think 4## is truly the proper class of codes (“4xx: Client Error - The request contains bad syntax or cannot be fulfilled.”) but reporting (or rather non-reporting as it is now) is the problem.
I think the call SHOULD fail as long as any item is not perfect, but with the proper explanation of what's wrong, otherwise we get to the no-solution problems like https://bitbucket.org/egh/zot4rst/issues/13/connection-refused-when-processing-with
By pchampin on 2015-09-14 14:50:14+00:00
@mecpl Let me restate : in the case where the request contain some good keys and some bad keys, I think that Zotxt should provide
- explicit information about which keys are bad (i.e. a better error message)
- the correct result for the good keys
So the answer in that case would be a partial success.
Theoretically, I agree that a partial success is also a partial failure (!), so a 4xx code is just as legitimate as a 2xx code -- but not more...
Pragmatically, however, a 4xx code will raise an exception in many HTTP libraries, and the "successful part" of the response would have to be extracted from the exception and re-injected in the "normal" course of the program. Inconvenient and ugly... That is why my preference goes to a 2xx code (but different from 200, to make it clear that this is not a complete success).
I hope this clarifies my proposition.
NB: actually, the "error message" for bad keys must not necessarily be handled differently from successful answers by the program. If all invalid keys were simply replaced by "[INVALID REFERENCE]" in the document, that would be enough for me.
By mcepl on 2015-10-03 22:08:38+00:00
I guess I am still not getting the proper way how to cite (and it is hopelessly underdocumented, IMHO). See this testing document.
By mcepl on 2015-10-03 22:10:31+00:00
... when using this library ....
By mcepl on 2015-10-03 22:11:58+00:00
... I get this (with zrst2rst
; also I get an error string>:12: (INFO/1) No role entry for "xcite" in module "docutils.parsers.rst.languages.en". Trying "xcite" as canonical role name.
I don't get this error with zrst2html, but both scripts generate same wrong references). Notice that the second citation of Jenkins’s book is generated as (Jenkins, 2011) instead of expected (Jenkins, 2009) (although both items are added to the generated bibliography in the end).
By egh on 2015-10-04 16:22:01+00:00
Hi Matěj,
You are doing everything correctly - something is wrong with the generation of the references. I'll file a new ticket for the issue.
https://bitbucket.org/egh/zot4rst/issues/14/wrong-reference
best, Erik