# Collapsing join delimiters

**URL:** <https://discourse.citationstyles.org/t/collapsing-join-delimiters/596>\
**Category:** CSL Development\
**Created:** [April 8, 2009, 12:38am UTC](https://discourse.citationstyles.org/t/collapsing-join-delimiters/596 "2009-04-08T00:38:41Z")\
**Posts on this page:** 7\
**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:** [April 8, 2009, 12:38am UTC](https://discourse.citationstyles.org/t/collapsing-join-delimiters/596/1 "2009-04-08T00:38:41Z")

</div>

I think I’ve finally gotten my head around the collapsing joins thing.  
Here’s a fresh proposal. It contradicts everything I’ve said about  
this so far, so a fresh thread.

We’re getting tangled up with a maze of options and attributes. We  
have year-suffix-delimiter, the delimiter on layout, and the  
delimiters on individual elements, and even in discussion we’re having  
trouble keeping straight which applies in a given use case. This is  
not a good sign.

Basically all that’s happening is that the first element rendered sets  
the prefix to be used in the event that it is joined with a previous  
rendered citation, and that is trumped by a range delimiter. If we  
express it that way in the CSL, I think it will dispel the confusion.  
We could do that with attributes “join-prefix” and  
"range-join-prefix", set on each of the relevant elements. A test is  
attached that illustrates the approach. It will correctly handle new  
use cases that Rinze has put forward, and (although it buries the  
prefix inside the CSL, which I originally thought would be hard to  
follow), I think it’s easier to understand on the face of the CSL.  
See what you think.

Frank

---

<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 8, 2009, 1:10am UTC](https://discourse.citationstyles.org/t/collapsing-join-delimiters/596/2 "2009-04-08T01:10:06Z")

</div>

I’ve not had a chance to look at this recent thread yet, but …On Tue, Apr 7, 2009 at 8:38 PM, Frank Bennett \<@Frank\_Bennett\> wrote:

> I think I’ve finally gotten my head around the collapsing joins thing.  
> Here’s a fresh proposal. It contradicts everything I’ve said about  
> this so far, so a fresh thread.
> 
> We’re getting tangled up with a maze of options and attributes. We  
> have year-suffix-delimiter, the delimiter on layout, and the  
> delimiters on individual elements, and even in discussion we’re having  
> trouble keeping straight which applies in a given use case. This is  
> not a good sign.
> 
> Basically all that’s happening is that the first element rendered sets  
> the prefix to be used in the event that it is joined with a previous  
> rendered citation, and that is trumped by a range delimiter. If we  
> express it that way in the CSL, I think it will dispel the confusion.  
> We could do that with attributes “join-prefix” and  
> “range-join-prefix”, set on each of the relevant elements. A test is  
> attached that illustrates the approach. It will correctly handle new  
> use cases that Rinze has put forward, and (although it buries the  
> prefix inside the CSL, which I originally thought would be hard to  
> follow), I think it’s easier to understand on the face of the CSL.  
> See what you think.

Notwithstanding what I think about it, it would be a  
backward-incompatible change. Is the problem solved worth the problems  
it would create?

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 8, 2009, 1:27am UTC](https://discourse.citationstyles.org/t/collapsing-join-delimiters/596/3 "2009-04-08T01:27:06Z")

</div>

> I’ve not had a chance to look at this recent thread yet, but …
> 
> > I think I’ve finally gotten my head around the collapsing joins thing.  
> > Here’s a fresh proposal. It contradicts everything I’ve said about  
> > this so far, so a fresh thread.
> > 
> > We’re getting tangled up with a maze of options and attributes. We  
> > have year-suffix-delimiter, the delimiter on layout, and the  
> > delimiters on individual elements, and even in discussion we’re having  
> > trouble keeping straight which applies in a given use case. This is  
> > not a good sign.
> > 
> > Basically all that’s happening is that the first element rendered sets  
> > the prefix to be used in the event that it is joined with a previous  
> > rendered citation, and that is trumped by a range delimiter. If we  
> > express it that way in the CSL, I think it will dispel the confusion.  
> > We could do that with attributes “join-prefix” and  
> > “range-join-prefix”, set on each of the relevant elements. A test is  
> > attached that illustrates the approach. It will correctly handle new  
> > use cases that Rinze has put forward, and (although it buries the  
> > prefix inside the CSL, which I originally thought would be hard to  
> > follow), I think it’s easier to understand on the face of the CSL.  
> > See what you think.
> 
> Notwithstanding what I think about it, it would be a  
> backward-incompatible change. Is the problem solved worth the problems  
> it would create?

I think so, but I’m not going to absorb the pain, so my opinion there  
doesn’t count for much. Simon or Elena may have views.

You could implement both join mechanisms, and deprecate the current  
style. The syntax doesn’t clash. That might satisfy everyone, and at  
some point you could drop the current options-based stuff. Note that  
Rintze has identified a need for a further option, to handle the join  
used on a year when the author is collapsed. If that were implemented  
only through the new method, it would be a bit of candy to attract  
style designers to adjust their code.

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:

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 …).

Frank

---

<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 8, 2009, 12:57pm UTC](https://discourse.citationstyles.org/t/collapsing-join-delimiters/596/4 "2009-04-08T12:57:08Z")

</div>

> > I’ve not had a chance to look at this recent thread yet, but …
> > 
> > > I think I’ve finally gotten my head around the collapsing joins thing.  
> > > Here’s a fresh proposal. It contradicts everything I’ve said about  
> > > this so far, so a fresh thread.
> > > 
> > > We’re getting tangled up with a maze of options and attributes. We  
> > > have year-suffix-delimiter, the delimiter on layout, and the  
> > > delimiters on individual elements, and even in discussion we’re having  
> > > trouble keeping straight which applies in a given use case. This is  
> > > not a good sign.
> > > 
> > > Basically all that’s happening is that the first element rendered sets  
> > > the prefix to be used in the event that it is joined with a previous  
> > > rendered citation, and that is trumped by a range delimiter. If we  
> > > express it that way in the CSL, I think it will dispel the confusion.  
> > > We could do that with attributes “join-prefix” and  
> > > “range-join-prefix”, set on each of the relevant elements. A test is  
> > > attached that illustrates the approach. It will correctly handle new  
> > > use cases that Rinze has put forward, and (although it buries the  
> > > prefix inside the CSL, which I originally thought would be hard to  
> > > follow), I think it’s easier to understand on the face of the CSL.  
> > > See what you think.
> > 
> > Notwithstanding what I think about it, it would be a  
> > backward-incompatible change. Is the problem solved worth the problems  
> > it would create?
> 
> I think so, but I’m not going to absorb the pain, so my opinion there  
> doesn’t count for much. Simon or Elena may have views.
> 
> You could implement both join mechanisms, and deprecate the current  
> style. The syntax doesn’t clash. That might satisfy everyone, and at  
> some point you could drop the current options-based stuff. Note that  
> Rintze has identified a need for a further option, to handle the join  
> used on a year when the author is collapsed. If that were implemented  
> only through the new method, it would be a bit of candy to attract  
> style designers to adjust their code.
> 
> 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:
> 
> 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 …).

Before the day begins in the US, I should note that I don’t have  
particularly strong feelings about the first item. Things will work  
as well with either approach (options or join attributes), so if it’s  
awkward to change the schema, I’ll happily fold. It’s important to  
cover the bases, though. From what we know so far, with the options  
approach we would need something like the following options:

It’s a judgement call whether the two range-delimiter options could be  
combined to a single one. If it’s safe to combine them, the range  
character could be defined as a locale term instead, and that option  
(i.e. the latter two of the four above) would not be needed.

Frank

---

<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 8, 2009, 2:48pm UTC](https://discourse.citationstyles.org/t/collapsing-join-delimiters/596/5 "2009-04-08T14:48:10Z")

</div>

…

> Before the day begins in the US, I should note that I don’t have  
> particularly strong feelings about the first item. Things will work  
> as well with either approach (options or join attributes), so if it’s  
> awkward to change the schema, I’ll happily fold. It’s important to  
> cover the bases, though.

We shouldn’t necessarily assume this last bit. There are some rules  
that are so stupid and awkward to implement that it’s not worth our  
bother. So we always need to keep in view the “won’t fix” option.

I’ve not read this whole earlier thread, and will just assume you’ve  
condensed it down to its essence.

> From what we know so far, with the options  
> approach we would need something like the following options:

The last one seems strange. What’s the use case? Surely it’s not  
something so silly as saying that what normally would be (Doe, 1999,  
2000) ought to be (Doe, 1999-2000)?

If it is, then my first impulse would be to put that in the “won’t  
fix” category, with the logic that it’s a stupid convention that’s a)  
confusing to a reader, b) adds processing complexity (even if  
minimal), and c) of negligible space-saving benefit.

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 8, 2009, 10:03pm UTC](https://discourse.citationstyles.org/t/collapsing-join-delimiters/596/6 "2009-04-08T22:03:23Z")

</div>

You’re right, that last one doesn’t make any sense.

Assuming that we’re going with the options based approach, here is a  
short description of each of the options and what they do, as a first  
shot at descriptive notes for the schema:

# collapse=“year” causes output of the author name to be suppressed

# if it is the same as in the preceding cite:

# Smith 1990, 1991On Wed, Apr 8, 2009 at 11:48 PM, Bruce D’Arcus \<@Bruce\_D\_Arcus1\> wrote:

> On Wed, Apr 8, 2009 at 8:57 AM, Frank Bennett \<@Frank\_Bennett\> wrote:
> 
> …
> 
> > Before the day begins in the US, I should note that I don’t have  
> > particularly strong feelings about the first item. Things will work  
> > as well with either approach (options or join attributes), so if it’s  
> > awkward to change the schema, I’ll happily fold. It’s important to  
> > cover the bases, though.
> 
> We shouldn’t necessarily assume this last bit. There are some rules  
> that are so stupid and awkward to implement that it’s not worth our  
> bother. So we always need to keep in view the “won’t fix” option.
> 
> I’ve not read this whole earlier thread, and will just assume you’ve  
> condensed it down to its essence.
> 
> > From what we know so far, with the options  
> > approach we would need something like the following options:
> 
> The last one seems strange. What’s the use case? Surely it’s not  
> something so silly as saying that what normally would be (Doe, 1999,  
> 2000) ought to be (Doe, 1999-2000)?
> 
> If it is, then my first impulse would be to put that in the “won’t  
> fix” category, with the logic that it’s a stupid convention that’s a)  
> confusing to a reader, b) adds processing complexity (even if  
> minimal), and c) of negligible space-saving benefit.

# 

# collapse=“year-suffix” causes output of both the author name and the

# year to be suppressed if they are the same as in the preceding cite:

# Smith 1990a,b

# 

# name=“year-delimiter” specifies the string used to join a year to the

# preceding cite when it is the first item rendered. With a value of

# ", " combined with collapse=“year” it will produce the following:

# Smith 1990, 1991; Jones 1992

# 

# name=“year-suffix-delimiter” specifies the string used to join a

# year-suffix to the preceding cite when it is the first item rendered.

# With a value of “,”, combined with collapse=“year-suffix” it will produce

# the following:

# Smith 1990a,b, 1991; Jones 1992

# 

# name=“year-suffix-range-delimiter” specifies that a sequence of

# three or more year-suffixes should be collapsed, with the first and

# last values separated by the specified string. With a value of

# “-”, combined with collapse=“year-suffix”, it will produce the

# following:

# Smith 1990a-c; Jones 1992

Frank

---

<div class="post-metadata">

**Author:** ![Rintze\_Zelle](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.citationstyles.org/rintze_zelle/32/175_2.png) [@Rintze\_Zelle](https://discourse.citationstyles.org/u/Rintze_Zelle)\
**Post date:** [April 9, 2009, 1:03pm UTC](https://discourse.citationstyles.org/t/collapsing-join-delimiters/596/7 "2009-04-09T13:03:41Z")

</div>

> Assuming that we’re going with the options based approach, here is a  
> short description of each of the options and what they do, as a first  
> shot at descriptive notes for the schema:
> 
> # collapse=“year” causes output of the author name to be suppressed
> 
> # if it is the same as in the preceding cite:
> 
> # Smith 1990, 1991
> 
> # 
> 
> # collapse=“year-suffix” causes output of both the author name and the
> 
> # year to be suppressed if they are the same as in the preceding cite:
> 
> # Smith 1990a,b

Shouldn’t ‘author’ be replaced by ‘contributor’?

> # 
> 
> # name=“year-delimiter” specifies the string used to join a year to the
> 
> # preceding cite when it is the first item rendered. With a value of
> 
> # ", " combined with collapse=“year” it will produce the following:
> 
> # Smith 1990, 1991; Jones 1992

One thing to keep in mind here is that ", " is currently hardcoded in Zotero  
as a year-delimiter. Current author-date styles in the Zotero Style  
Repository will break if no delimiter is added by citeproc when this option  
is absent (which I guess is the desired behavior).

RintzeOn Thu, Apr 9, 2009 at 12:03 AM, Frank Bennett \<@Frank\_Bennett\>wrote: