et al. for short form names

CSL Development
1

Today, I noticed that, when citeproc-js is formatting more than et-al-
min names in a parenthetical citation (with no et-al element in
), it outputs:

(Smith, et al. 2008)

whereas Zotero’s old implementation would output (correctly, according
to CMS)

(Smith et al. 2008)

Regarding the “et-al” element, the spec currently says that it:

Configures formatting of the et al substitution. Only necessary to
deviate from default rendering (for example, to italicize the string).

The behavior Zotero uses (which no one has complained about so far, as
far as I know) is to add a comma between the author name and "et al."
only when et-al-use-first is greater than 1. If we want to make things
simpler than that, I would argue that the default should be not to
include the comma.

In the process, I also discovered that, at least according to
Wikipedia, the latest version of APA asks for this:

Brown, A.B., Johnson, C., Laird, K., Howard, O. P., Evans, S., . . .
Pritchard, J. (2004)

when the citation has more than six authors. This makes a lot of
sense, but as far as I know, we can’t currently handle it in CSL.

Simon

2

Today, I noticed that, when citeproc-js is formatting more than et-al-
min names in a parenthetical citation (with no et-al element in
), it outputs:

(Smith, et al. 2008)

whereas Zotero’s old implementation would output (correctly, according
to CMS)

(Smith et al. 2008)

Regarding the “et-al” element, the spec currently says that it:

Configures formatting of the et al substitution. Only necessary to
deviate from default rendering (for example, to italicize the string).

The behavior Zotero uses (which no one has complained about so far, as
far as I know) is to add a comma between the author name and “et al.”
only when et-al-use-first is greater than 1. If we want to make things
simpler than that, I would argue that the default should be not to
include the comma.

Response here:

http://groups.google.com/group/citeproc-js/browse_thread/thread/841f648a6afea877

In the process, I also discovered that, at least according to
Wikipedia, the latest version of APA asks for this:

Brown, A.B., Johnson, C., Laird, K., Howard, O. P., Evans, S., . . .
Pritchard, J. (2004)

when the citation has more than six authors. This makes a lot of
sense, but as far as I know, we can’t currently handle it in CSL.

This has been previously discussed, but so far no decision has been made on
how to implement it:

http://sourceforge.net/mailarchive/message.php?msg_id=53208a5f0909230501m5951a5b1x388d345ac7571f40%40mail.gmail.com

RintzeOn Mon, Apr 26, 2010 at 11:31 AM, Simon Kornblith <@Simon_Kornblith>wrote:

3

According to CMS (15th edition, 6.23):
“When it [edit: i.e. “et-al”] follows a single item, it requires no
preceding or following comma; when it follows two or more names, the second
comma is optional.”

As the current Zotero-behavior is the most complex option, I agree we should
keep it as the default. I’m not sure what’s the best way to override this
though. There are some styles that also require a comma when only a single
name is shown:


As earlier proposed, we could have the value of the prefix element on
cs:et-al override the default context-sensitive et-al-prefix, so that

results in
(Smith, et al. 2008)
(Smith, Doe, et al. 2007)

RintzeOn Mon, Apr 26, 2010 at 11:31 AM, Simon Kornblith <@Simon_Kornblith>wrote:

4

Today, I noticed that, when citeproc-js is formatting more than et-al-
min names in a parenthetical citation (with no et-al element in
), it outputs:

(Smith, et al. 2008)

whereas Zotero’s old implementation would output (correctly, according
to CMS)

(Smith et al. 2008)

According to CMS (15th edition, 6.23):
“When it [edit: i.e. “et-al”] follows a single item, it requires no
preceding or following comma; when it follows two or more names, the second
comma is optional.”

As the current Zotero-behavior is the most complex option, I agree we should
keep it as the default. I’m not sure what’s the best way to override this
though. There are some styles that also require a comma when only a single
name is shown:

Modifying et al - Zotero Forums
What other citation formats would you like Zotero to generate? - Zotero Forums

As earlier proposed, we could have the value of the prefix element on
cs:et-al override the default context-sensitive et-al-prefix, so that

results in

(Smith, et al. 2008)
(Smith, Doe, et al. 2007)

I’m inclined to agree.

5

After a bit of discussion with Frank, I realized the context-dependency (the
use of the comma based on the number of names rendered) really only affects
the upgrading of styles from CSL 0.8 to 1.0. The number of names rendered
when et-al abbreviation is applied isn’t dependent on the input data:
instead it’s fixed by the value of et-al-use-first. So, my modified proposal
for CSL 1.0 is:

a) by default, a space is prepended to the et-al term.
b) this space is replaced by the value of the prefix attribute on cs:et-al
(when set)

Case A - default================

and

result in

(Smith et al. 2008) [for et-al-use-first=“1”]
(Smith, Doe et al. 2007) [for et-al-use-first=“2”]

Case B - overriding prefix

results in

(Smith, et al. 2008) [for et-al-use-first=“1”]
(Smith, Doe, et al. 2007) [for et-al-use-first=“2”]

If we choose for this option, we can extend upgrade.xls to add the cs:et-al
element (with a prefix of ", ") after cs:name to those CSL 0.8 styles that
have et-al-use-first set to a value higher than 1 (for which the Zotero CSL
processor would use a comma-space).

Rintze

6

Surprisingly, Frank didn’t notice it, but the premise in my previous email,
“The number of names rendered when et-al abbreviation is applied isn’t
dependent on the input data: instead it’s fixed by the value of
et-al-use-first”, is incorrect. Disambiguation attempts can increase the
number of names rendered, so my earlier solution would give rise to some
problems. A modified proposal:

The CSL 1.0 specification should be modified. The new behavior should be
similar to that of the current Zotero CSL processor: the et-al term is
preceded by a space when a single name is rendered, and preceded by the
name-delimiter (e.g. ", ") when multiple names are rendered.

In CSL 1.1, we could add a new name-option to offer more fine-grained
control: delimiter-precedes-et-al, with the same values (default would be
"contextual", with alternative values “always” and “never”) and behavior as
delimiter-precedes-last.

In this proposal, we lose the proposed prefix overwriting ability, which
felt like abusing CSL anyhow.

RintzeOn Wed, Apr 28, 2010 at 10:44 AM, Rintze Zelle <@Rintze_Zelle>wrote:

7

Surprisingly, Frank didn’t notice it, but the premise in my previous email,
“The number of names rendered when et-al abbreviation is applied isn’t
dependent on the input data: instead it’s fixed by the value of
et-al-use-first”, is incorrect. Disambiguation attempts can increase the
number of names rendered, so my earlier solution would give rise to some
problems.

Ooops. Exactly right.

A modified proposal:

The CSL 1.0 specification should be modified. The new behavior should be
similar to that of the current Zotero CSL processor: the et-al term is
preceded by a space when a single name is rendered, and preceded by the
name-delimiter (e.g. ", ") when multiple names are rendered.

Looks like the best bet for the present.

In CSL 1.1, we could add a new name-option to offer more fine-grained
control: delimiter-precedes-et-al, with the same values (default would be
“contextual”, with alternative values “always” and “never”) and behavior as
delimiter-precedes-last.

I keep forgetting exactly what delimiter-precedes-last does, and
travelling back to the documentation. For 1.1, a
possibly-easier-to-follow approach might be to provide paired
attributes to the cs:et-al element, @prefix-single and
@prefix-multiple, as a mutually-exclusive alternative to @prefix. If
a cs:and element were introduced, it could be handled in the same way,
and delimiter-precedes-last could go away.

In this proposal, current default behavior would be expressed like this:

(Actually it would be preferable to move cs:et-al, and a new cs:and
element inside cs:name itself, but we can discuss that when we dig
into this in earnest.)

8

Surprisingly, Frank didn’t notice it, but the premise in my previous email,
“The number of names rendered when et-al abbreviation is applied isn’t
dependent on the input data: instead it’s fixed by the value of
et-al-use-first”, is incorrect. Disambiguation attempts can increase the
number of names rendered, so my earlier solution would give rise to some
problems.

Ooops. Exactly right.

A modified proposal:

The CSL 1.0 specification should be modified. The new behavior should be
similar to that of the current Zotero CSL processor: the et-al term is
preceded by a space when a single name is rendered, and preceded by the
name-delimiter (e.g. ", ") when multiple names are rendered.

Looks like the best bet for the present.

Context sensitivity for implicit et-al terms has been installed in
citeproc-js v.1.0.3, in anticipation of Rintze’s proposed amendment to
the specification.

Frank

9

I don’t think this would be an improvement. My main objection (other than
that delimiter-precedes-last functions fine in CSL 0.8) is that you’d
confuse the concept of affixes. When not defined on an attribute, prefixes
should not be applied. The “prefix-single” and “prefix-multiple” attributes
don’t offer context-dependent formatting, and I think it’s confusing to have
contextual prefixes by default.

RintzeOn Fri, Apr 30, 2010 at 11:57 PM, Frank Bennett <@Frank_Bennett>wrote:

10

In CSL 1.1, we could add a new name-option to offer more fine-grained
control: delimiter-precedes-et-al, with the same values (default would
be
“contextual”, with alternative values “always” and “never”) and behavior
as
delimiter-precedes-last.

I keep forgetting exactly what delimiter-precedes-last does, and
travelling back to the documentation. For 1.1, a
possibly-easier-to-follow approach might be to provide paired
attributes to the cs:et-al element, @prefix-single and
@prefix-multiple, as a mutually-exclusive alternative to @prefix. If
a cs:and element were introduced, it could be handled in the same way,
and delimiter-precedes-last could go away.

In this proposal, current default behavior would be expressed like this:

(Actually it would be preferable to move cs:et-al, and a new cs:and
element inside cs:name itself, but we can discuss that when we dig
into this in earnest.)

I don’t think this would be an improvement.

That’s perfectly possible. :slight_smile:

My main objection (other than
that delimiter-precedes-last functions fine in CSL 0.8) is that you’d
confuse the concept of affixes. When not defined on an attribute, prefixes
should not be applied.

The same would be true here. The single/multiple special prefixes
would be available only on the special elements, like cs:et-al. On
those elements, if no value is given for prefix, prefix-single or
prefix-multiple, you get no prefix on the element.

The “prefix-single” and “prefix-multiple” attributes
don’t offer context-dependent formatting, and I think it’s confusing to have
contextual prefixes by default.

The single/multiple attributes would indeed provide context-dependent
formatting: on cs:et-al, if the element is preceded by a single name,
use prefix-single (or prefix, if that’s set instead); if it’s preceded
by multiple names, use prefix-multiple (or prefix, if that’s set
instead).

Hmm … with respect to contextual prefixes, did you mean to say that
it’s confusing not to have contextual prefixes by default? If so, I
take your point; with your proposal, default prefix behavior of
cs:et-al could be aligned with the current implicit default, and that
would be a very good thing.

Would a consequence of your delimiter-precedes-et-al proposal be that
the prefix attribute becomes unavailable on cs:et-al? That seems to
be the logical outcome, but just to confirm.

11

In CSL 1.1, we could add a new name-option to offer more fine-grained
control: delimiter-precedes-et-al, with the same values (default would
be
“contextual”, with alternative values “always” and “never”) and behavior
as
delimiter-precedes-last.

I keep forgetting exactly what delimiter-precedes-last does, and
travelling back to the documentation. For 1.1, a
possibly-easier-to-follow approach might be to provide paired
attributes to the cs:et-al element, @prefix-single and
@prefix-multiple, as a mutually-exclusive alternative to @prefix. If
a cs:and element were introduced, it could be handled in the same way,
and delimiter-precedes-last could go away.

In this proposal, current default behavior would be expressed like this:

(Actually it would be preferable to move cs:et-al, and a new cs:and
element inside cs:name itself, but we can discuss that when we dig
into this in earnest.)

I don’t think this would be an improvement.

That’s perfectly possible. :slight_smile:

My main objection (other than
that delimiter-precedes-last functions fine in CSL 0.8) is that you’d
confuse the concept of affixes. When not defined on an attribute, prefixes
should not be applied.

The same would be true here. The single/multiple special prefixes
would be available only on the special elements, like cs:et-al. On
those elements, if no value is given for prefix, prefix-single or
prefix-multiple, you get no prefix on the element.

The “prefix-single” and “prefix-multiple” attributes
don’t offer context-dependent formatting, and I think it’s confusing to have
contextual prefixes by default.

The single/multiple attributes would indeed provide context-dependent
formatting: on cs:et-al, if the element is preceded by a single name,
use prefix-single (or prefix, if that’s set instead); if it’s preceded
by multiple names, use prefix-multiple (or prefix, if that’s set
instead).

Hmm … with respect to contextual prefixes, did you mean to say that
it’s confusing not to have contextual prefixes by default? If so, I
take your point; with your proposal, default prefix behavior of
cs:et-al could be aligned with the current implicit default, and that
would be a very good thing.

Would a consequence of your delimiter-precedes-et-al proposal be that
the prefix attribute becomes unavailable on cs:et-al? That seems to
be the logical outcome, but just to confirm.

Now that I’m persuaded … and if it’s right that the prefix attribute
of cs:et-al will be dropped to make room for delimiter-precedes-et-al
… would it make sense to amend the specification now, and align the
behavior of cs:et-al with the implicit et al. term?

Frank

12

(Actually it would be preferable to move cs:et-al, and a new cs:and
element inside cs:name itself, but we can discuss that when we dig
into this in earnest.)

Agreed this makes more sense. But clearly something for CSL 1.1.

My main objection (other than
that delimiter-precedes-last functions fine in CSL 0.8) is that you’d
confuse the concept of affixes. When not defined on an attribute,
prefixes
should not be applied.

The same would be true here. The single/multiple special prefixes
would be available only on the special elements, like cs:et-al. On
those elements, if no value is given for prefix, prefix-single or
prefix-multiple, you get no prefix on the element.

The “prefix-single” and “prefix-multiple” attributes

don’t offer context-dependent formatting, and I think it’s confusing to
have
contextual prefixes by default.

The single/multiple attributes would indeed provide context-dependent
formatting: on cs:et-al, if the element is preceded by a single name,
use prefix-single (or prefix, if that’s set instead); if it’s preceded
by multiple names, use prefix-multiple (or prefix, if that’s set
instead).

Ah, yes. Sorry. So my main objection is that, if a style author wants to
italicize the et-al term, (s)he shouldn’t have to specify affixes (or
prefix-single/multiple attributes) just to keep existing behavior. E.g.

and

should behave the same (apart from the italics), and both should offer
context-dependent punctuation.

Hmm … with respect to contextual prefixes, did you mean to say that

it’s confusing not to have contextual prefixes by default? If so, I
take your point; with your proposal, default prefix behavior of
cs:et-al could be aligned with the current implicit default, and that
would be a very good thing.

This thread is getting confusing, but I think I agree :).

Would a consequence of your delimiter-precedes-et-al proposal be that
the prefix attribute becomes unavailable on cs:et-al? That seems to
be the logical outcome, but just to confirm.

Affixes are also unavailable on cs:name-part, which is somewhat similar. So
I think we can scrap them from cs:et-al as well.

Now that I’m persuaded … and if it’s right that the prefix attribute

of cs:et-al will be dropped to make room for delimiter-precedes-et-al
… would it make sense to amend the specification now, and align the
behavior of cs:et-al with the implicit et al. term?

Yes.

RintzeOn Fri, Apr 30, 2010 at 11:57 PM, Frank Bennett <@Frank_Bennett>wrote:

13

Based on this discussion, I modified the spec:

I also opened a ticket for the proposed delimiter-precedes-et-al attribute:

RintzeOn Sun, May 2, 2010 at 10:07 AM, Rintze Zelle <@Rintze_Zelle>wrote:

14

Just letting you all know that I wrote an addition to the spec for the
proposed delimiter-precedes-et-al attribute. Comments welcome.

RintzeOn Thu, May 13, 2010 at 10:46 AM, Rintze Zelle <@Rintze_Zelle>wrote: