DOI ending with a period, not resolving
I think this is a minor bug, but when a DOI ends with a period in the "DOI" field, it does not resolve correctly.
For instance "10.4140/TCP.n.2019.109." , leads here "https://doi.org/10.4140/TCP.n.2019.109" when clicking "DOI" (Go to this item online) in the standalone.
Perhaps the period is trimmed because it's more likely a mistake? Probably not a best practice to have a DOI end with a period?
Thanks, hope this isn't duplicate or insufficient detail.
For instance "10.4140/TCP.n.2019.109." , leads here "https://doi.org/10.4140/TCP.n.2019.109" when clicking "DOI" (Go to this item online) in the standalone.
Perhaps the period is trimmed because it's more likely a mistake? Probably not a best practice to have a DOI end with a period?
Thanks, hope this isn't duplicate or insufficient detail.
Technical: I think Zotero is calling ZU.cleanDOI on the DOI before resolving this, which raises a number of questions:
1. Should ZU.cleanDOI remove trailing periods in DOIs
pro: we're likely going to see many cases where periods are incorrectly included in DOIs, especially in URL notation
con: it's not always correct, see this example
Assuming ZU.cleanDOI is left unchanged
2. Should ZU.cleanDOI be called when using add by identifier (it currently does)
pro: people paste DOIs incorrectly (e.g. as URL, with doi: prefix, etc.) and this fixes that.
con: The above DOI won't resolve and there's no way to make it resolve
3. Should Zotero call ZU.cleanDOI when resolving DOIs
pro: it'll resolve incorrectly entered DOIs
con: it won't resolve the DOI above
I'm unsure about 1 and 2, but I think 3 is pretty clear cut: The current behavior is undesirable. People shouldn't have incorrect DOIs in their metadata since they also produce incorrect citations, so Zotero shouldn't expect them, especially not as it breaks other behavior (without any workarounds).
adamsmith, I agree that 3 is intuitively wrong right now.
For 1, I agree about parsing a URL or formatted bibliography, etc., but if provided directly as metadata by the publisher, maybe don't trim anything, if the translators can make that distinction?
As for 2, why not try both and then fall back to adding a dot? I guess that would double the number of requests made for any failed lookup, but it's possible. (And assuming that only a dot would be stripped from the end, and no other alternatives. I'm not sure about that! Or, if necessary, remember the original input and revert to that if the trimmed version doesn't work, or instead you could try the original input first and if it resolves, great, if not try trimming-- assuming there's no 'security'/bug-avoiding feature with trimming to strip illegal characters from the input.)
The code for resolving DOIs from the item pane:
https://github.com/zotero/zotero/blob/5bb2486040fa1fc617c81b4aea756ba338584f6b/chrome/content/zotero/bindings/itembox.xml#L428
Would be easy to not clean up or to just clean up anything preceding 10.
And ZU.cleanDOI
https://github.com/zotero/zotero/blob/f531ac7b60b138cd57294bde328890b1063260d8/chrome/content/zotero/xpcom/utilities.js#L242
So it indeed removes final commas and periods