Commas

CSL Development
1

Okay, so this is quite irritating. In APA style, you’re supposed to do the
following for an in-text citation with two authors:

(Wegener & Petty, 1994)

But for a footnote, you’re supposed to do:

Wegener, D. T., & Petty, R. E. (1994). Mood management across affective
states: The hedonic contingency hypothesis. Journal of Personality & Social
Psychology, 66, 1034-1048.

Notice how, in the first, there’s no comma before the & sign, but in the
second, there is.

I suspect this would be easily solved with an extra attribute (on
/ or on /). While we’re at it, it
may make sense to add an attribute to control the serial comma, which is
another obnoxious and seemingly separate issue (“Kernis, Cornell, Sun,
Berry, & Harlow, 1993” [the correct APA in-text citation] vs. “Kernis,
Cornell, Sun, Berry & Harlow, 1993”).

Should I go ahead and modify the APA CSL file and/or schema to handle this?

In unrelated news, I have now integrated my CSL parser with Microsoft Word
for Mac. For now, it’s quite rudimentary, but it works, and it should be
easy to port to Windows. I look forward to showing it to you when we release
our beta (which we’ve delayed to add new features, since the Mozilla Corp.
has delayed Firefox 2).

And, another thought: does it make sense to start using the SF tracker for
CSL issues?

Thanks,
Simon

2

Okay, so this is quite irritating.

Indeed. Never noticed that one.

Notice how, in the first, there’s no comma before the & sign, but in
the
second, there is.

I suspect this would be easily solved with an extra attribute (on
/ or on /).

This is another consequence of the localized approach BTW. Previously,
one could have just done .

While we’re at it, it may make sense to add an attribute to control
the serial comma, which is another obnoxious and seemingly separate
issue (“Kernis, Cornell, Sun,
Berry, & Harlow, 1993” [the correct APA in-text citation] vs. “Kernis,
Cornell, Sun, Berry & Harlow, 1993”).

But are these different? Seems the same case: a prefix before the
“and”. Could be solved with an and-prefix attribute in fact (though
that introduces an inconsistency).

Alternately, you could think of it as a delimiter for that separates
the last name, with the “and” an additional label.

Should I go ahead and modify the APA CSL file and/or schema to handle
this?

Yeah, but can you just post your suggest schema changes here first
given the above?

In unrelated news, I have now integrated my CSL parser with Microsoft
Word
for Mac.

Excellent!

For now, it’s quite rudimentary, but it works, and it should be
easy to port to Windows. I look forward to showing it to you when we
release
our beta (which we’ve delayed to add new features, since the Mozilla
Corp.
has delayed Firefox 2).

Yeah, I was wondering about that. So are you use real Word field for
storing the citations, or just dumb text markers. Obviously the former
could be preferable, and consistent with what MS is going in Word 2007.

And, another thought: does it make sense to start using the SF tracker
for
CSL issues?

Yeah, absolutely. Do you have rights for that?

Bruce

3

While we’re at it, it may make sense to add an attribute to control
the serial comma, which is another obnoxious and seemingly separate
issue (“Kernis, Cornell, Sun,
Berry, & Harlow, 1993” [the correct APA in-text citation] vs. “Kernis,
Cornell, Sun, Berry & Harlow, 1993”).

But are these different? Seems the same case: a prefix before the
“and”. Could be solved with an and-prefix attribute in fact (though
that introduces an inconsistency).

Alternately, you could think of it as a delimiter for that separates
the last name, with the “and” an additional label.

But the problem is that in the APA citation, that last comma does not exist
when there are only two authors (Kernis & Cornell, 1993), but does exist
when there are three (Kernis, Cornell, & Sun, 1993). In the bibliography,
the comma is always there. So it seems like we need three options:

  1. No serial comma ever
  2. Serial comma for 3 or more authors
  3. Always a serial comma

Perhaps, on :

attribute serial-comma { “never” | “three-authors” | “always” }?

I suppose “three-authors” is a slightly clunky name for a value. An
alternative would be to make that behavior the default, and allow { “never”

“always”}, but then the behavior of a given CSL file is slightly less
transparent. I suppose we could always clear things up in the documentation.

In unrelated news, I have now integrated my CSL parser with Microsoft
Word
for Mac.

Excellent!

For now, it’s quite rudimentary, but it works, and it should be
easy to port to Windows. I look forward to showing it to you when we
release
our beta (which we’ve delayed to add new features, since the Mozilla
Corp.
has delayed Firefox 2).

Yeah, I was wondering about that. So are you use real Word field for
storing the citations, or just dumb text markers. Obviously the former
could be preferable, and consistent with what MS is going in Word 2007.

So far, we’re just using dumb text markers. If I can figure out how to embed
a large amount of data into a Word file, I might be able to store the actual
citations, too.

And, another thought: does it make sense to start using the SF tracker
for
CSL issues?

Yeah, absolutely. Do you have rights for that?

I don’t have admin rights, so I can’t create actual meaningful categories
(right now the only one is “Interface Improvements (example)”), and I’m not
sure if it will allow me to assign/accept tickets, but I think that I can
create them.

Simon

4

But the problem is that in the APA citation, that last comma does not exist
when there are only two authors (Kernis & Cornell, 1993), but does exist
when there are three (Kernis, Cornell, & Sun, 1993). In the bibliography,

Argh!!!

the comma is always there. So it seems like we need three options:

  1. No serial comma ever
  2. Serial comma for 3 or more authors
  3. Always a serial comma

Perhaps, on :

attribute serial-comma { “never” | “three-authors” | “always” }?

I suppose “three-authors” is a slightly clunky name for a value. An
alternative would be to make that behavior the default, and allow { “never”

“always”}, but then the behavior of a given CSL file is slightly less
transparent. I suppose we could always clear things up in the documentation.

First, please change cs:name to cs:names.

For this particular problem, what about …

attribute delimiter-on-last-min { xsd:integer }

…? Or something like that. The “serial-comma” term is conufusing to
me, and it might be good to leave it flexible?

Just an idea.

So far, we’re just using dumb text markers. If I can figure out how to embed
a large amount of data into a Word file,

Peter Sefton (who is heading an Australian-based project that aims to
do soemthing simliar to SF) had been thinking about not worrying about
embedding, but instead using smart URLs/URIs.

I might be able to store the actual
citations, too.

The lastest Open XML ECMA draft (released just the other day) has some
more detail on the new citation field. See if you can take a look at
that, if for no other reason to get them feedback so the spec is
clear.

And, another thought: does it make sense to start using the SF tracker
for
CSL issues?

Yeah, absolutely. Do you have rights for that?

I don’t have admin rights, so I can’t create actual meaningful categories
(right now the only one is “Interface Improvements (example)”), and I’m not
sure if it will allow me to assign/accept tickets, but I think that I can
create them.

I’ll see about chanigng your rights then.

Bruce

5

That’s a reasonable way of doing it, too, although it seems like the default
behavior would have to be no delimiter on the last, which is probably the
least frequently used option. I’m not particularly picky about the way this
is done, but it seems like we need some control over it.

Simon

6

Hmm … right. The default behavior (e.g. without need of this
attribute) is that “and” gets no preceding comma. So then:

attribute and-preceding-comma { “always” | “never” | “when-more-than-two” }

…? A little ugly.

Bruce

7

I suppose this should really be “and-preceding-delimiter” (or
"delimiter-precedes-last") since it seems like (soon to be )
has a “delimiter” attribute in the most recent versions of the styles. I
agree that there’s no concise way of phrasing that last option. Perhaps it
should just be the default, since it’s how one uses “and” in everyday
language?

Simon