biting the bullet on et al, etc.

…? Why move the choose outside of names? Am not opposed (I have no

opinion really); just not immediately seeing.

Allowing macros in , or adding to , would require
some significant schema complications, since right now only a very limited
subset of elements are allowed in (or at least that’s what I recall,
since is essentially a variable type).

  1. It isn’t backwards compatible (although it would be easy to convert

existing styles)

Right. Would be true of adding the et-al element as well though.

Not necessarily. We could revert to formatting as we do now if no et-al
element is present.

So which do you prefer? I’m agnostic; just want to fix the hole.

Bruce

Not necessarily. We could revert to formatting as we do now if no et-al
element is present.

So which do you prefer? I’m agnostic; just want to fix the hole.

OK, I think I’ll make an executive decision. Let’s:

  1. add a “year-suffix” variable

  2. add an et-al element to names:

et-al = element cs:et-al { attribute alternate-term { “and-others” }?,
formatting }

That seems to solve these problems in the most backward-compatible ways.

Aside: I don’t much like the “et-al” element name, but I suppose
that’s merely aesthetic.

Bruce

Is anything holding back the introduction of the et-al element? It hasn’t
yet appeared in the schema.

Rintze

I just added it, and had to make a number of other changes to some
pattern names to accommodate it. Can you please test?

Configures formatting of the et al substitution. Only necessary

to deviate from

default rendering (for example, to italicize the string).

et-al = element cs:et-al {
## where other than standard et-al string is needed
attribute alternate-term { “and-others” }?,
formatting
}

Bruce2009/3/21 Rintze Zelle <@Rintze_Zelle>:

How exactly? This would require changes in Zotero, right?

Rintze

Yes. I mean, test the schema.

Bruce2009/3/22 Rintze Zelle <@Rintze_Zelle>:

I’m not sure if I get the use of the “and-others” attribute. Could you
please give me an example with the expected output?

Thanks,
Andrea

Doe, Smith, and others

E.g. some styles use different terms to represent what is normally “et
al”. We’d want to add that as a term, then.

Bruce

Is anything holding back the introduction of the et-al element? It hasn’t
yet appeared in the schema.

I just added it, and had to make a number of other changes to some
pattern names to accommodate it. Can you please test?

Configures formatting of the et al substitution. Only necessary

to deviate from

default rendering (for example, to italicize the string).

et-al = element cs:et-al {
## where other than standard et-al string is needed
attribute alternate-term { “and-others” }?,
formatting
}

I’m not sure if I get the use of the “and-others” attribute. Could you
please give me an example with the expected output?

I was puzzled by this, too. I’ve code it to work like this:

Which with et al handling will render (mapping and-others to the “and
others” term from the locale):

John Doe, and others

I’m not sure if that’s exactly what’s intended, though. Should the
hyphen be replaced with a space in the argument to alternate-term?
That way you could map to an arbitrary locale term.

Frank

ah, sorry but I didn’t see the related addition to cs:terms.

Thanks,
Andrea

I was puzzled by this, too. I’ve code it to work like this:

Which with et al handling will render (mapping and-others to the “and
others” term from the locale):

John Doe, and others

Right, though we need to figure out what to do about the “comma”
issue; perhaps if the element is present, the prefix must be
explicitly set?

I’m not sure if that’s exactly what’s intended, though. Should the
hyphen be replaced with a space in the argument to alternate-term?

I don’t understand. Can you restate?

I do not that the term option is “and others” but in the new element I
did “and-others.” Any preferences?

Bruce

No problem. Would people prefer I change the new "alternate-term"
attribute to just the existing “term”?

Bruce

I was puzzled by this, too. I’ve code it to work like this:

Which with et al handling will render (mapping and-others to the “and
others” term from the locale):

John Doe, and others

Right, though we need to figure out what to do about the “comma”
issue; perhaps if the element is present, the prefix must be
explicitly set?

I’m not sure if that’s exactly what’s intended, though. Should the
hyphen be replaced with a space in the argument to alternate-term?

I don’t understand. Can you restate?

I do not that the term option is “and others” but in the new element I
did “and-others.” Any preferences?

Sorry, it may just be me getting tangled up again; quite possibly I’m
just misreading the RNG. There is a locale term already with the key,
“and others”, without a hyphen:

... et al. ... and others ...

Where it says “and-others” in the RNG file, is that a placeholder that
means, “put an appropriate term key here”? If so, I’m just puzzling
over a non-issue. But if that means “and-others is the only valid
argument here, and it will map to the ‘and others’ term” then it seems
like it would be more natural to use the actual locale key.

Sorry for the extra traffic, if this is a red herring.

Frank

Sorry, it may just be me getting tangled up again; quite possibly I’m
just misreading the RNG. There is a locale term already with the key,
“and others”, without a hyphen:

... et al. ... and others ...

Where it says “and-others” in the RNG file, is that a placeholder that
means, “put an appropriate term key here”? If so, I’m just puzzling
over a non-issue. But if that means “and-others is the only valid
argument here, and it will map to the ‘and others’ term” then it seems
like it would be more natural to use the actual locale key.

I need to check that, but was referring to the value for
“alternate-term”, which includes a hyphen.

Bruce

Sorry, I’m dense. What exactly should be tested?

Rintze

I just added it, and had to make a number of other changes to some
pattern names to accommodate it. Can you please test?

How exactly? This would require changes in Zotero, right?

Yes. I mean, test the schema.

Bruce

Sorry, I’m dense. What exactly should be tested?

I think Bruce means the syntax constraints imposed by RELAX NG in emacs etc.

Meanwhile, it’s been implemented in citeproc-js:

// book::seven-names-1
{
“type”: “book”,
“author”: [
{ “name”:“Чайковский, Пётр Ильич” },
{ “name”:“van Winkle, Rip” },
{ “name”:“我妻, 栄” },
{ “name”:“Thucydides, Carl, III” },
{ “name”:“Tokugawa, Ieyasu !” },
{ “name”:“Ministry of Fear, Loathing and Error !!” },
{ “name”:“Prince” }
],
“issued”: “2000”,
“title”: “Our Story”
}

// names/test025.txt
{
“citation”:[ {“source”:“book::seven-names-1”} ],
“testof”: “citation”,
“csl”:"

", "result":"Пётр Ильич ЧАЙКОВСКИЙ, Rip van WINKLE, 我妻栄, Carl THUCYDIDES III, TOKUGAWA Ieyasu, et al." }

Frank2009/3/22 Rintze Zelle <@Rintze_Zelle>:

Whether the schema works as expected WRT validation of the new
cs:et-al element. E.g. try modifying a style to add et-al styliing,
and see if a) it looks right, and b) it validates correctly…

Works best if you’re using a validating editor, of course.

Bruce2009/3/22 Rintze Zelle <@Rintze_Zelle>:

So my thought was that this …

// names/test025.txt
{
“citation”:[ {“source”:“book::seven-names-1”} ],
“testof”: “citation”,
“csl”:"

", "result":"Пётр Ильич ЧАЙКОВСКИЙ, Rip van WINKLE, 我妻栄, Carl THUCYDIDES III, TOKUGAWA Ieyasu, et al." }

Should, therefore, not have the ", " prefix before the et al. Does
everyone agree?

In essence, we’d then be saying the old approach is only legacy, and
we cleanly separate out the new approach.

Bruce

So my thought was that this …

// names/test025.txt
{
“citation”:[ {“source”:“book::seven-names-1”} ],
“testof”: “citation”,
“csl”:"

", "result":"Пётр Ильич ЧАЙКОВСКИЙ, Rip van WINKLE, 我妻栄, Carl THUCYDIDES III, TOKUGAWA Ieyasu, et al." }

Should, therefore, not have the ", " prefix before the et al. Does
everyone agree?

In essence, we’d then be saying the old approach is only legacy, and
we cleanly separate out the new approach.

I don’t know what the old approach was, so I’ll need a little guidance
on this one. Can you provide a set of examples of CSL that illustrate
the difference, and the output each should produce?

Frank

The old approach is magic: print the et-al term at the end of the
author list with a preceding ", " (which, then, is an implicit
prefix).That’s what you’re doing.

So what I’m suggesting is just that the prefix be required when using cs:et-al:

I’m just wondering if people agree.

Bruce