Hi everyone,
we got a question over at Zotero on page-range-format and locators.
Currently, citeproc-js doesn’t apply the page range format to
locators, even if the locators are a page range.
I wanted to check
a) how this is done in the other implementations (Andrea, Sylvester, Charles?)
b) ask what the preferred way of handling this is so that we can
include it in the specs.
Thoughts?–
Sebastian Karcher
Ph.D. Candidate
Department of Political Science
Northwestern University
It looks like the processor in Papers has the same issue. It would be fairly easy to properly support the page range format. I suppose it makes sense that it should?
Charles
citeproc-ruby applies the page-range-format only to the variable=“page” case on text nodes – so this is essentially the same behaviour, right?
The locators are something I always wanted to look at in more detail, because I had the feeling I didn’t get it right exactly (the page ranges being one of the points in question actually), because of the naming overlaps between CSL and the JSON input format.
My interpretation was this: in the input I have a ‘locator’ and a ‘label’ – the locator holds the actual value, the label holds one of the names defined by CSL as proper locators here:
http://citationstyles.org/downloads/specification.html#locators
So when I have text node with variable=“locator” I can fetch the locator value from the citation item and then also fetch the label value from the item. If label is “page” then I can apply the page range format – which would essentially solve the issue, right? Sebastian, is that what you mean by the implicit locator=“page”? I might have this confused, as I said earlier : )
Sylvester
Yes, Sylvester, that’s exactly what I think should happen (and this
behavior should be documented in the spec as well).
Rintze
It turns out that citeproc-js is already set up to apply numeric
collapsing to the locator variable, but only if it is rendered with
cs:number (which would be invalid in both CSL and CSL-m):
So I guess this could be turned on, after a little more testing. It
does seem odd that the variables most likely to need numeric
collapsing (page and locator) are both cast as non-numeric in the
schema, though.
Frank