Do not mangle strings when page-range-format="expanded"?

[fbennett]

With page-range-format="expanded", the processor attempts to expand the numbers making up a range to a form that makes logical sense as a sequence. So "110-5" becomes "110-115".

This requires that we impose some rather dangerous assumptions on the content string submitted by the user. It may be, for example, that "110-5" is a leaf number (i.e. "the 5th appended revision to paragraph 110"). In that case, the pinpoint will be corrupted -- and in a smoothly presented way that may not be caught before publication.

I think we really ought to be trusting the user's content here, and refrain from performing this "expansion".

I would propose that the option be retained, but simply pass through the string verbatim, replacing hyphen with en-dash. I think this would be much safer.

Thoughts?

[rmzelle]

Is this an issue if page-range-format expansion only affects the page variable? Wouldn't you store the leaf number somewhere else?

[fbennett]

If it's a range, there could conceivably be leaf numbers on both ends, so they would all have to go into the same field. I don't have a concrete use case to hand, it just seems like something that could come up.

[rmzelle]

Considering that styles can just not use page-range-format="expanded", and that this issue will never come up for a significant set of styles (e.g. those for the sciences) where the option is useful, I don't think changing the behavior of the option is a good idea.

We might want to revisit under which conditions the hyphen is replaced by an en-dash, though, but that's a different discussion.

[fbennett]

Thanks, good feedback. In the current pre-release I've eased in a small change to behavior, for the odd case of ranges of "numbers" that are a mixture of letters and numerals. These will now be "expanded" only if the hyphen delimiter has spaces on either side; but for vanilla numbers like 10-5, things still work as before, so 10-5 -> 10-15.

[jrcaldwell]

I have come across a real life case where this function may be useful. Since 1989 the European Court Reports (ECR) have been split into two volumes. Where present, the volume number should attach to the page number and not the report series. As far as I am aware this format is widely used by legal styles citing ECR materials.

E.g.Case C-422/99 French Republic v Commission [2002] ECR I-4397

Presently, the citation drops the -4397 as it is treated as a page range. Perhaps it would be cleaner to have a page first and page last field to allow for these sort of situations.

[fbennett]

On Wed, Oct 19, 2011 at 10:14 AM, caldwelljules reply@reply.github.com wrote:

I have come accross a real life case where this function may be useful. Since 1989 the European Court Reports (ECR) have been split into two volumes. Where present, the volume number should attach to the page number and not the report series. As far as I am aware this format is widely used by legal styles citing ECR materials.

E.g.Case C-422/99 French Republic v Commission [2002] ECR I-4397

Presently, the citation drops the -4397 as it is treated as a page range. Perhaps it would be cleaner to have a page first and page last field to allow for these sort of situations.

It is possible to render the entire field, rather than the first page. For types that normally provide only the first page of the source, that should cover things.

Reply to this email directly or view it on GitHub: https://github.com/citation-style-language/schema/issues/81#issuecomment-2454076

[bwiernik]

I think this is just a documentation issue. Yes, there should be no expansion. @fbennett Does citeproc-js still do this?