This weekend, I’m overhauling some of the names code in citeproc-js,
to fix some long-standing bugs in attribute inheritance. One of the
test failures doesn’t actually look like a failure, and I’d like to
confirm that I’m not misreading the spec.
In the fixture, a value for et-al-min is set on separate cs:name nodes
inside cs:citation and cs:bibliography, and a value of 2 for
et-al-use-first is set on the cs:citation node. The test renders the
bibliography.
The bibliography comes out with all three names given in the input.
The fixture RESULT has one name, truncated by et al.
I don’t see anything in the spec about defaulting to a value of 1 for
et-al-use-first, and it says that “[u]se of these two attributes
enables et-al abbreviation.” Since the test provides a value for only
one of the attributes inside cs:bibliography, it sounds like listing
all three names there is the right thing to do (and the original
RESULT string was wrong).
Just to let you know, the test in question passes in citeproc-ruby too.
After some digging I found the commit that sets the default to 1 to
refer to this being citeproc-js’ default value specifically (likely
inferred from the test at hand). If you remove the default value, I’ll
also remove it from citeproc-ruby.
Great. I’ve removed the constraint in the current processor release,
but it might be restored after discussion. From a quick check of the
repo, it looks like five styles rely on the default value. If that’s
roughly representative of styles in the wild, the impact will be
small, but some people might be bitten.
Two additional styles use an extremely high value for et-al-min,
presumably with the intention of listing all authors; those would not
be (much) affected.
Curious to hear the views of @adam42smith and @rmzelle on the issue.
Just to confirm that I agree the default shouldn’t be there (and removing
it will make reviewing a tiny bio easier for Rintze and me. Thanks!Sent from my phone
Also agree. Can’t recall ever reading about a default, don’t think
it’s a good idea, and it’s not the intent of the current spec to allow
setting only one of the two et-al parameters of a set ("…-min" and
"…-use-first" for “et-al-…” and “et-al-subsequent-…”).
With the hierarchical name attributes, it’s not entirely
straightforward to test for the presence of both with validation, but
otherwise we’d screen for it. Maybe we should require that both
attributes of a set should occur on the same element. That would also
make it easier to ascertain that the “…-min” attribute has a higher
value than the “…-use-first” attribute, which is commonly violated
in submissions.
Also agree. Can’t recall ever reading about a default, don’t think
it’s a good idea, and it’s not the intent of the current spec to
allow
setting only one of the two et-al parameters of a set (“…-min” and
“…-use-first” for “et-al-…” and “et-al-subsequent-…”).
With the hierarchical name attributes, it’s not entirely
straightforward to test for the presence of both with validation, but
otherwise we’d screen for it. Maybe we should require that both
attributes of a set should occur on the same element. That would also
make it easier to ascertain that the “…-min” attribute has a higher
value than the “…-use-first” attribute, which is commonly violated
in submissions.
I don’t think it’s hard to write a test case for both cases (which
handles inheritance) – shall I give it a try?
Quick update: Sylvester very helpfully created tests to find
problematic instances where et-al-(subsequent-)min is missing its
et-al-(subsequent-)use-first partner and vice versa, and where the
*-min isn’t higher than *-use-first. We fixed the 43 offending styles,
and are now testing for this going forward. Details at