Proper format for page ranges in citeproc-json

I see that CSL defines page range format (http://citationstyles.org/downloads/specification.html#appendix-v-page-range-formats) for determining how page ranges are supposed to display. I just want to verify that in the citeproc-json format, it is good and proper to always give the full numbers in the page range? I.e., it should be "page": "479-482", and not "page": "479-82"?

I notice that the json produced by Mendeley has the latter, and I suspect that it is wrong, but I want to make sure.

Thanks.

Chris Maloney
NIH/NLM/NCBI (Contractor)
Building 45, 5AN.24D-22
301-594-2842

Yes, absolutely. Full information should be in the data.

As Frank says, the full date range is clearly and always preferred,
but CSL processors should (and citeproc-js can) convert 479-82 to
479-482 when page-range-format=“expanded” is set (which isn’t the case
for most styles at this time, but could be done relatively easily if
it’s important).

Hi,On 2 May 2014 21:50, Maloney, Christopher (NIH/NLM/NCBI) [C] <@Maloney_Christopher> wrote:

I see that CSL defines page range format (http://citationstyles.org/downloads/specification.html#appendix-v-page-range-formats) for determining how page ranges are supposed to display. I just want to verify that in the citeproc-json format, it is good and proper to always give the full numbers in the page range? I.e., it should be "page": "479-482", and not "page": "479-82"?

I notice that the json produced by Mendeley has the latter, and I suspect that it is wrong, but I want to make sure.

Yes, this is wrong. My guess is that the original “page” field in the
Document details is 479-82. AFAIR we just pass the page there - we
don’t manipulate it at all.

From: Carles Pina [mailto:@Carles_Pina]
Hi,

I see that CSL defines page range format
(http://citationstyles.org/downloads/specification.html#appendix-v-page-
range-formats) for determining how page ranges are supposed to display. I
just want to verify that in the citeproc-json format, it is good and proper to
always give the full numbers in the page range? I.e., it should be "page": "479-482", and not "page": "479-82"?

I notice that the json produced by Mendeley has the latter, and I suspect
that it is wrong, but I want to make sure.

Yes, this is wrong. My guess is that the original “page” field in the Document
details is 479-82. AFAIR we just pass the page there - we don’t manipulate it

As Frank says, the full date range is clearly and always preferred, but CSL
processors should (and citeproc-js can) convert 479-82 to
479-482 when page-range-format=“expanded” is set (which isn’t the case for
most styles at this time, but could be done relatively easily if it’s
important).

Frank Bennett wrote:

Yes, absolutely. Full information should be in the data.

Yeah, a lot of people would say it’s not important: “it’s cosmetic”. But, of course, just about everything related to citation styles is cosmetic. I’d rather see the “hub format”, i.e. the citeproc-json, be somewhat strict in this, and unambiguously require the “full information”, “479-482”. That would lower the burden on the processors, and would help to guarantee consistent behavior across processors, and when the CSLs don’t specify a page-range-format.

Chris Maloney
NIH/NLM/NCBI (Contractor)
Building 45, 5AN.24D-22
301-594-2842

oh, no, that’s a misunderstanding. Of course I consider getting
citations exactly right important. Everything else would be rather
silly in the context of this list.
What I meant was that we could set page-range-format=“expanded” for
all styles that don’t have anything else set if that is important to
help reference managers get citations right.
With Zotero this is pretty much a non-issue, I’ve hardly ever seen the
shortened page ranges imported (i.e. from the Zotero perspective this
isn’t imporant/makes no difference either way).

FWIW, if anyone wants to quickly clean up a set of page ranges you can
use this simple script to do it:

Just pipe in your page-ranges one per line and it will return the
expanded page range.

signature.asc (198 Bytes)