Bug? subsequent-author-substitute - label remains in bibliography

pauli

In the bibliography one can set the option

subsequent-author-substitute="----"

to replace the names of the author(s) with a string (e.g. "----") if more than one book of the same author(s) is in the bibliography.

IMHO this should work in the way that the contents of the <names> tag is replaced by the replacement string.

However, if there is a <label> in the <names> block, e.g.

<names variable="editor" suffix=": " font-style="italic">
<name name-as-sort-order="all" sort-separator=", " delimiter=" / "/>
<label form="short" prefix=" (" suffix=")"/>
</names>

then the label does not get replaced. It stays in the bibliography but looses all the formatting of the <names> tag.

To me that looks like a bug.

adamsmith

keeping the label is desired. Everything else would be super confusing -- if you have an author of a book and editor another book, you do want the substitute to kick in, but you don't want to lose the label because their role different.

The fact that it does lose the formatting on the label is a bug -- but inheriting the formatting is rather tricky to do, IIRC, so I'm not sure how keen fbennett is going to be to fix this given that the workaround (simply also setting the formatting attribute on the label) is simple.

fbennett

To me that looks like a bug.

The fact that it does lose the formatting on the label is a bug

It would be a bug if the CSL Specification requires that formatting attributes set on cs:names be applied to its child labels. Does it?

adamsmith

I don't think it does very explicitly (though I often miss these things, so Rintze may correct me), but I think formatting attributes should (and generally do) always apply to all child elements. Anything else would be rather confusing, no?

But even if we leave this question open, the current behavior is inconsistent:
formatting is applied for child labels in cs:names in regular cases
formatting is removed for child labels cs:names when subsequent-author-substitute kicks in.

One of these is clearly incorrect. I'd argue the second one. Do you disagree?

fbennett

The desired scope of the styling is unclear when set on cs:names. It could cover delimiters and affixes, and it might not. It might cover the affixes on the child cs:label, and it might not. I would be good to figure out what exact behaviour is desired, and specify it formally. I'll follow whatever the spec says.

Meanwhile, I seem to be getting different results on different systems. An earlier version of the processor was behaving as you describe; but a newer installation is applying the formatting to the label in all cases (the behaviour that you favour). Not sure what the deal is, I'll post again when I've had time to look into it in more detail.

Rintze

The desired scope of the styling is unclear when set on cs:names. It could cover delimiters and affixes, and it might not. It might cover the affixes on the child cs:label, and it might not. I would be good to figure out what exact behaviour is desired, and specify it formally. I'll follow whatever the spec says.

You're right that the spec is rather unclear on this topic. The only spec language I could find is "With the exception of affixes set on cs:layout, affixes are outside the scope of formatting, quotes, strip-periods and text-case attributes set on the same element (as a workaround, these attributes take effect on affixes when set on a parent cs:group element)." (http://docs.citationstyles.org/en/stable/specification.html#affixes)

(We also have an open ticket to https://github.com/citation-style-language/documentation/pull/34, which seems to suggest adding a similar exception as we have for cs:layout to cs:group.)

So per the 1.0.1 spec, formatting attributes on cs:names should not affect affixes on the same element.

In general, I think it makes sense that any formatting set on a parent element affects all the output of a child element. So formatting on cs:names should probably cover the affixes on a child cs:label. I'm not sure we ever discussed how formatting should affect delimiters (I couldn't quickly dig up any discussion, at least).

adamsmith

Yes, I think given that formatting for groups includes affixes of group elements, we should generalize that to all parent-child elements.

I'd also say we should include group and other delimiters since those would commonly substitute affixes. Also <b>text</b>, <b>text</b> is just wrong. Less convinced on this latter point, though.

fbennett

It would be good to have a full set of examples along with clear language in the spec.