# year-suffix as number (was Collapsing join delimiters)

**URL:** <https://discourse.citationstyles.org/t/year-suffix-as-number-was-collapsing-join-delimiters/598>\
**Category:** CSL Development\
**Created:** [April 9, 2009, 2:16pm UTC](https://discourse.citationstyles.org/t/year-suffix-as-number-was-collapsing-join-delimiters/598 "2009-04-09T14:16:35Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Bruce\_D\_Arcus1](https://avatars.discourse-cdn.com/v4/letter/b/4bbf92/32.png) [@Bruce\_D\_Arcus1](https://discourse.citationstyles.org/u/Bruce_D_Arcus1)\
**Post date:** [April 9, 2009, 2:16pm UTC](https://discourse.citationstyles.org/t/year-suffix-as-number-was-collapsing-join-delimiters/598/1 "2009-04-09T14:16:35Z")

</div>

…

> A related item just occurred to me, which is kind of important. The  
> year-suffix delimiters are numbers, and things will be much less messy  
> at the implementation level if they are expressed with a number  
> element:

Are you still advocating this?

> The current schema will work, but in order to implement range joins of  
> the suffixes, every implementation will want to trap the  
> “variable-suffix” variable and recharacterize it as a number  
> internally. It would save a lot of confusion in the code if it were  
> just declared to be a number in the first place. That would also let  
> editors use roman numbers, or parens-enclosed arabic numerals, or  
> whatever as disambiguation strings, and they would all delimit and  
> range correctly out of the box, using standard numbers handling  
> machinery. A text element with a year-suffix var is bound to a single  
> style of presentation, which could bite down the road  
> (year-suffix-roman … year-suffix-roman-square-braces …).

But I don’t why this has anything in particular to do with the CSL syntax?

I personally think it’s a little awkward either way. The advantage of  
the approach I took is that it required totally trivial mods to the  
schema (just adding an attribute value).

Bruce

---

<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:** [April 9, 2009, 2:55pm UTC](https://discourse.citationstyles.org/t/year-suffix-as-number-was-collapsing-join-delimiters/598/2 "2009-04-09T14:55:56Z")

</div>

> …
> 
> > A related item just occurred to me, which is kind of important. The  
> > year-suffix delimiters are numbers, and things will be much less messy  
> > at the implementation level if they are expressed with a number  
> > element:
> 
> Are you still advocating this?

It will work either way for the familiar a-z use case, but with a text  
element, that sequencing scheme is hard-wired; you can’t easily get  
roman numerals or arabic numerals. If someone came along asking for  
that capability, you _could_ cope by treating year-suffix as an  
implicit number, and permitting number attributes on such variables  
… but if implicit numbers behave the same whether they are rendered  
through text or number, it becomes unclear what the number element is  
doing there.

I don’t feel strongly about it, if it’s easier to leave it as text,  
that’s fine (but secretly I might pretend that it’s a number anyway  
:).

> > The current schema will work, but in order to implement range joins of  
> > the suffixes, every implementation will want to trap the  
> > “variable-suffix” variable and recharacterize it as a number  
> > internally. It would save a lot of confusion in the code if it were  
> > just declared to be a number in the first place. That would also let  
> > editors use roman numbers, or parens-enclosed arabic numerals, or  
> > whatever as disambiguation strings, and they would all delimit and  
> > range correctly out of the box, using standard numbers handling  
> > machinery. A text element with a year-suffix var is bound to a single  
> > style of presentation, which could bite down the road  
> > (year-suffix-roman … year-suffix-roman-square-braces …).
> 
> But I don’t why this has anything in particular to do with the CSL syntax?

It’s the loss of form=“roman”, mostly.

> I personally think it’s a little awkward either way. The advantage of  
> the approach I took is that it required totally trivial mods to the  
> schema (just adding an attribute value).

It’s not super-difficult to recharacterize the value as a number  
internally in the implementation, but it would be simpler the other  
way around. More lines of code to read, more stuff to break. It’s a  
judgment call, apart from the roman numerals thing.