# Multiple numbers in cs:number

**URL:** <https://discourse.citationstyles.org/t/multiple-numbers-in-cs-number/914>\
**Category:** CSL Development\
**Created:** [November 13, 2010, 1:10am UTC](https://discourse.citationstyles.org/t/multiple-numbers-in-cs-number/914 "2010-11-13T01:10:58Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![Frank\_Bennett](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.citationstyles.org/frank_bennett/32/198_2.png) [@Frank\_Bennett](https://discourse.citationstyles.org/u/Frank_Bennett)\
**Post date:** [November 13, 2010, 1:10am UTC](https://discourse.citationstyles.org/t/multiple-numbers-in-cs-number/914/1 "2010-11-13T01:10:58Z")

</div>

The CSL 1.0 specification currently says this about cs:number:

“If a variable displayed with cs:number contains a mixture of numeric  
and non-numeric text, only the first number encountered is used for  
rendering (e.g. “12” when the entire string is “12th edition”).”

[http://citationstyles.org/downloads/specification.html#number](http://citationstyles.org/downloads/specification.html#number)

While making fixes in response to some of the recent activity on the  
Zotero forums, it occurred to me that it would be kind for cs:number  
to recognize, and apply formatting to, more than one number. For  
example, we might have input like this:

volume: 11-15

If rendered with , the  
specified rule would produce this output:

xi

Whereas a user will certainly expect something like this:

xi-xv

I have extended citeproc-js a little to handle this case, and I’d like  
to propose a change to the specification along these lines:

“If a variable displayed with cs:number contains no characters other  
than numbers, and optionally one or more connecting comma, space,  
hyphen or ampersand characters, each number in the variable will be  
rendered with appropriate formatting (e.g. “3 & 4” rendered with  
form=“ordinal” becomes “3rd & 4th”). If additional characters are  
included in the input, only the first number encountered is used for  
rendering (e.g. “12” when the entire string is “12th edition”).”

What do you think?

Frank

---

<div class="post-metadata">

**Author:** ![Carles\_Pina](https://avatars.discourse-cdn.com/v4/letter/c/dbc845/32.png) [@Carles\_Pina](https://discourse.citationstyles.org/u/Carles_Pina)\
**Post date:** [November 13, 2010, 1:48am UTC](https://discourse.citationstyles.org/t/multiple-numbers-in-cs-number/914/2 "2010-11-13T01:48:00Z")

</div>

Hi,

> While making fixes in response to some of the recent activity on the  
> Zotero forums, it occurred to me that it would be kind for cs:number  
> to recognize, and apply formatting to, more than one number. For  
> example, we might have input like this:
> 
> volume: 11-15
> 
> If rendered with , the  
> specified rule would produce this output:
> 
> xi
> 
> Whereas a user will certainly expect something like this:
> 
> xi-xv
> 
> I have extended citeproc-js a little to handle this case, and I’d like  
> to propose a change to the specification along these lines:
> 
> “If a variable displayed with cs:number contains no characters other  
> than numbers, and optionally one or more connecting comma, space,  
> hyphen or ampersand characters, each number in the variable will be  
> rendered with appropriate formatting (e.g. “3 & 4” rendered with  
> form=“ordinal” becomes “3rd & 4th”). If additional characters are  
> included in the input, only the first number encountered is used for  
> rendering (e.g. “12” when the entire string is “12th edition”).”
> 
> What do you think?

In general speaking, I usually prefer to give to citeproc-js as well  
detailed and defined as I can\*. So in this case I would prefer to  
break up the number variable to have a “start” and “end” elements  
instead of free text. And that the users of citeproc-js / citation  
engine should handle it (forcing the input in two fields, splitting  
the input somehow, etc.).

(\*): well, I’m giving freedom to citeproc-js about particles in the  
names for example…

Other option would be to do the same than “date”: we have date-parts  
(or similar) or free text. At least in citeproc-js level, not sure  
what CSL 1.0 says about it specifically.

Cheers,

---

<div class="post-metadata">

**Author:** ![Frank\_Bennett](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.citationstyles.org/frank_bennett/32/198_2.png) [@Frank\_Bennett](https://discourse.citationstyles.org/u/Frank_Bennett)\
**Post date:** [November 13, 2010, 1:55am UTC](https://discourse.citationstyles.org/t/multiple-numbers-in-cs-number/914/3 "2010-11-13T01:55:00Z")

</div>

> Hi,
> 
> > While making fixes in response to some of the recent activity on the  
> > Zotero forums, it occurred to me that it would be kind for cs:number  
> > to recognize, and apply formatting to, more than one number. For  
> > example, we might have input like this:
> > 
> > volume: 11-15
> > 
> > If rendered with , the  
> > specified rule would produce this output:
> > 
> > xi
> > 
> > Whereas a user will certainly expect something like this:
> > 
> > xi-xv
> > 
> > I have extended citeproc-js a little to handle this case, and I’d like  
> > to propose a change to the specification along these lines:
> > 
> > “If a variable displayed with cs:number contains no characters other  
> > than numbers, and optionally one or more connecting comma, space,  
> > hyphen or ampersand characters, each number in the variable will be  
> > rendered with appropriate formatting (e.g. “3 & 4” rendered with  
> > form=“ordinal” becomes “3rd & 4th”). If additional characters are  
> > included in the input, only the first number encountered is used for  
> > rendering (e.g. “12” when the entire string is “12th edition”).”
> > 
> > What do you think?
> 
> In general speaking, I usually prefer to give to citeproc-js as well  
> detailed and defined as I can\*. So in this case I would prefer to  
> break up the number variable to have a “start” and “end” elements  
> instead of free text. And that the users of citeproc-js / citation  
> engine should handle it (forcing the input in two fields, splitting  
> the input somehow, etc.).

But there could be holes in the sequence: “3, 4 & 6”.

---

<div class="post-metadata">

**Author:** ![Frank\_Bennett](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.citationstyles.org/frank_bennett/32/198_2.png) [@Frank\_Bennett](https://discourse.citationstyles.org/u/Frank_Bennett)\
**Post date:** [November 13, 2010, 2:00am UTC](https://discourse.citationstyles.org/t/multiple-numbers-in-cs-number/914/4 "2010-11-13T02:00:01Z")

</div>



---

<div class="post-metadata">

**Author:** ![Frank\_Bennett](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.citationstyles.org/frank_bennett/32/198_2.png) [@Frank\_Bennett](https://discourse.citationstyles.org/u/Frank_Bennett)\
**Post date:** [November 13, 2010, 4:58am UTC](https://discourse.citationstyles.org/t/multiple-numbers-in-cs-number/914/5 "2010-11-13T04:58:47Z")

</div>

My intuition was correct (and led to some bug fixes in the numbers  
handling machinery, which is all to the good). In response to Carles’  
objection to passing through possibly-broken connecting punctuation,  
I’ve extended the logic to assume more complete control over  
punctuation and formatting in the target case.

Since calling applications would have to do something similar in order  
to supply pre-parsed content, embedding this logic in the processor  
seems likely to serve the purpose at lower social cost.

This should play nice with the companion proposal to open up issue,  
volume and edition as variables available for use with cs:label, with  
its contextual pluralization behavior.

Here’s a revised proposal for the specification:On Sat, Nov 13, 2010 at 11:00 AM, Frank Bennett \<@Frank\_Bennett\> wrote:

> On Sat, Nov 13, 2010 at 10:55 AM, Frank Bennett \<@Frank\_Bennett\> wrote:
> 
> > On Sat, Nov 13, 2010 at 10:48 AM, Carles Pina \<@Carles\_Pina\> wrote:
> > 
> > > Hi,
> > > 
> > > On 13 November 2010 01:10, Frank Bennett \<@Frank\_Bennett\> wrote:
> > > 
> > > > While making fixes in response to some of the recent activity on the  
> > > > Zotero forums, it occurred to me that it would be kind for cs:number  
> > > > to recognize, and apply formatting to, more than one number. For  
> > > > example, we might have input like this:
> > > > 
> > > > volume: 11-15
> > > > 
> > > > If rendered with , the  
> > > > specified rule would produce this output:
> > > > 
> > > > xi
> > > > 
> > > > Whereas a user will certainly expect something like this:
> > > > 
> > > > xi-xv
> > > > 
> > > > I have extended citeproc-js a little to handle this case, and I’d like  
> > > > to propose a change to the specification along these lines:
> > > > 
> > > > “If a variable displayed with cs:number contains no characters other  
> > > > than numbers, and optionally one or more connecting comma, space,  
> > > > hyphen or ampersand characters, each number in the variable will be  
> > > > rendered with appropriate formatting (e.g. “3 & 4” rendered with  
> > > > form=“ordinal” becomes “3rd & 4th”). If additional characters are  
> > > > included in the input, only the first number encountered is used for  
> > > > rendering (e.g. “12” when the entire string is “12th edition”).”
> > > > 
> > > > What do you think?
> > > 
> > > In general speaking, I usually prefer to give to citeproc-js as well  
> > > detailed and defined as I can\*. So in this case I would prefer to  
> > > break up the number variable to have a “start” and “end” elements  
> > > instead of free text. And that the users of citeproc-js / citation  
> > > engine should handle it (forcing the input in two fields, splitting  
> > > the input somehow, etc.).
> > 
> > But there could be holes in the sequence: “3, 4 & 6”.
> 
> On the other hand, I may have missed something in my current patch.  
> citeproc-js has range collapsing logic for numbers that should be able  
> to handle this case, if the discretionary prefixes are set correctly.  
> Hmm …

* * *

If a variable rendered with cs:number contains no characters other  
than numbers, and optionally one or more connecting comma, space,  
hyphen or ampersand characters, it is treated as a list. In this  
case, the intervening punctuation is ignored, and the list is sorted  
and rendered with appropriate connecting punctuation (e.g. “4, 3 & 5”  
rendered with form=“ordinal” becomes “3rd-5th”).

If additional characters are included in the input, only the first  
number encountered is used for rendering (e.g. “12” when the entire  
string is “12th edition”).

* * *