What I do not understand is why, if we decide to use an integer
because of possible future extension, don’t we just add the extended
feature all together. That is to say, “et-al-use-last” will be an
integer indicating the number of names to be put after the ellipses
(1, 10, or 1000, as long as we have enough contributors). And that’s
it.
The reasons for restricting et-al-use-last to “1”/true and “0”/false were a)
we aren’t currently aware of any styles using more than one trailing author
and b) it is not immediately obvious how multiple trailing authors should be
rendered (see
http://bitbucket.org/bdarcus/csl-schema/issue/14/list-last-authors-name-in-truncated#comment-202954
).
That’s it in a nutshell. If a style with multiple trailing authors
eventually emerges, it might require that the last of the trailing
authors be preceded by “and”, or it might not. I’ll work with any
decision that emerges from the group, but I think we’re
over-engineering this. My personal preference would be to do the
minimum needed to cleanly resolve the known use case, and move on.
That would mean sticking with values “true” or “false” for the
present.
The reasoning behind that preference is that the time we invest in
discussing the multiple-trailing-authors case does not produce any
immediately useful results, and quite possibly will turn out to have
been wasted effort. Avoiding a distant and uncertain prospect of
doing some code refactoring down the road isn’t worth the candle, in
my view.
Anyway, here are the options and the trade-offs.
[A] Implement et-al-use-last, with values false or true
Risks: if multiple trailing authors is ever required, then …
(1) must change data type
(2) must refactor code
[B] Implement et-al-use-last, with values 0 or 1 only.
Risks:
(1) if multiple trailing authors is ever required, must refactor code
(2) documentation on multiple trailing authors encourages
emergence of such a style
[C] Implement et-al-use-last, with arbitrary numeric value
Risks: final join is a blind guess, so …
(1) if multiple trailing authors is required, might need to
refactor final joins
(2) further discussion will be needed to settle the best-guess
choice of final join
(2) if the option is never needed, development effort is wasted
[D] Implement et-al-use-last, with arbitrary numeric value, and
specify post-ellipsis join
Risks:
(1) further discussion needed to settle how to control final join
(2) if the option is never used, development effort is wasted
My own vote is [A], then [B], then [D], then [C], ranked from most to
least desirable. But I’ll follow whatever the group decides.
Frank