"(1) Would it be safe for the processor to always strip a DOI URL prefix stub from the initial input?"
I would go one step further, and strip any prefix from the DOI variable values, not only URL prefixes in the form of "https?://(dx.)?doi.org\/" but also a preceding "doi:" (case-insensitive). "(2) If "yes" to (1), should non-DOI prefixes also be stripped? (If "no," citeproc-js would need to avoid affixing the URL stub in this case.)" I think you miswrote "non-DOI" here (like Sebastian I'm confused). If you mean "non-URL prefixes", the answer would be "yes" (per above). "(3) Should special handling be introduced for a prefix hard-coded as in the above example? (If the prefix is always to be "https://doi.org/,"; it would be cleaner to have a proper CSL attribute that triggers its inclusion.)" Probably yes. I'm not sure if we just need to be able to URLify the DOI and URL variables, or need something more general (I vaguely recall somebody on the Zotero forums who wished to hyperlink either the title or entire bibliographic entry for a custom style). Rintze On Fri, Dec 8, 2017 at 9:45 PM, Sebastian Karcher <karc...@u.northwestern.edu> wrote: > 1) So what you're saying is -- don't print the prefix at all, and the print > a URLified DOI? That's always safe, yes. There's no other reason for that > prefix than to URLify > 2) Could you give an example? You mean http-type prefixes? I don't think we > have any others. > 3) Yes, absolutely, now that everyone agrees how DOIs should be displayed, > there should be a CSL function for it -- we'll likely have still allow plain > form, but something like <text variable="DOI" as-link="true"/> I think is > appropriate. > > On Fri, Dec 8, 2017 at 9:07 PM, Frank Bennett <biercena...@gmail.com> wrote: >> >> Dan has flagged an issue with DOIs: >> >> https://github.com/Juris-M/citeproc-js/issues/57 >> >> To sum up, some styles prepend the URL stub to a DOI for display as a >> hard-coded prefix, and in that case the (citeproc-js) processor wraps >> only the DOI itself in an anchor. >> >> It would be cleaner to wrap the entire URL. Hacking the processor to >> recognize the URL stub and merge it into the field content could be >> done, but I would be more comfortable if that and any associated >> behavior were specified in CSL. We would be talking about constructs >> like this: >> >> <text variable="DOI" prefix="https://doi.org/"/> >> >> As things stand at present in the citeproc-js processor, there are >> several parts to the issue: >> >> (1) Would it be safe for the processor to always strip a DOI URL >> prefix stub from the initial input? That would assure a consistent >> starting point, to avoid returning a corrupted URL. >> >> (2) If "yes" to (1), should non-DOI prefixes also be stripped? (If >> "no," citeproc-js would need to avoid affixing the URL stub in this >> case.) >> >> (3) Should special handling be introduced for a prefix hard-coded as >> in the above example? (If the prefix is always to be >> "https://doi.org/,"; it would be cleaner to have a proper CSL attribute >> that triggers its inclusion.) >> >> Thoughts most welcome! >> >> FB >> >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> _______________________________________________ >> xbiblio-devel mailing list >> xbiblio-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/xbiblio-devel > > > > > -- > Sebastian Karcher, PhD > www.sebastiankarcher.com > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > xbiblio-devel mailing list > xbiblio-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/xbiblio-devel > ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ xbiblio-devel mailing list xbiblio-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
