bugreports_EnvAndUrb test seems contrary to disambiguation rules

CSL Development
1

Here is a link to the test

It expects the output to be

>>[0] Baines, T S, O Benedettini and J M Kay, ‘Title One’; Baines, T S, F Gump and J M Kay, ‘Title Two’.
..[1] See reference 1, Baines et al.
>>[2] See reference 1, Baines et al.

These are still ambiguous because

  • Note [1] refers to the first cite in note [0], and
  • Note [2] refers to the second cite in note [0]

It needn’t be that way because the CSL offers two <if disambiguate="true”> elements. One adds the author and the other adds the title. The title would disambiguate.

The rule for <if disambiguate="true”> elements is

element content is only rendered if it disambiguates two otherwise identical citations

By that rule, it seems the output of the test should be

>>[0] Baines, T S, O Benedettini and J M Kay, ‘Title One’; Baines, T S, F Gump and J M Kay, ‘Title Two’.
..[1] See reference 1, ‘Title One’.
>>[2] See reference 1, ‘Title Two’.

The test is keeping the choice that does not disambiguate and discarding the choice that does. Why?

This is the relevant CSL:

<group delimiter=", ">
	<text variable="first-reference-note-number" prefix="See reference "/>
	<choose>
		<if disambiguate="true">
			<names variable="author">
				<name form="short" and="text" sort-separator=", " delimiter=", " delimiter-precedes-last="never" et-al-min="3" et-al-use-first="1" initialize-with=" "/>
			</names>
		</if>
	</choose>
	<choose>
		<if disambiguate="true">
			<text variable="title" quotes="true" text-case="title" form="short"/>
		</if>
	</choose>
</group>
2

I agree this doesn’t seem right (presumably that’s why there was a bug report?). Maybe @Frank_Bennett recalls or can reconstruct the logic of the test from the initial note?

1 Like
3

I am also wondering now why the first citation should be

Baines, T S, O Benedettini and J M Kay, ‘Title One’; Baines, T S, F Gump and J M Kay, ‘Title Two’

rather than

Baines, Benedettini and Kay, ‘Title One’; Baines, Gump and Kay, ‘Title Two’.

Baines and Kay are the same person in both cites (or at least have the same complete name) and the style has <name initialize="false”/>.

Maybe that too is part of the bug? Or I could well be missing something.

For now I’m editing my local copy of the test to

>>===== RESULT =====>>
>>[0] Baines, Benedettini and Kay, ‘Title One’; Baines, Gump and Kay, ‘Title Two’.
..[1] See reference 1, ‘Title One’.
>>[2] See reference 1, ‘Title Two’.
<<===== RESULT =====<<

and tagging it for follow-up so I can move on. :slightly_smiling_face:

4

I agree.

The cites in the the first note match position="first" and the <else> branch takes effect (see position attribute in https://docs.citationstyles.org/en/stable/specification.html#choose). Thus the <name> in that branch doesn’t have form="short" and the names are rendered with all parts.

      <choose>
        <if position="subsequent">
          ...
        </if>
        <else>
          <group delimiter=", ">
            <names variable="author">
              <name and="text" sort-separator=", " delimiter=", " delimiter-precedes-last="never" initialize-with=" " name-as-sort-order="first" initialize="false"/>
            </names>
            <text variable="title" quotes="true"/>
          </group>
        </else>
      </choose>
5

In disambiguate_IncrementalExtraText.txt, the contents of <if disambiguate="true"> branches are added incrementally for disambiguation method (3). This means the reasonable result for bugreports_EnvAndUrb.txt should be as follows.

>>[0] Baines, T S, O Benedettini and J M Kay, ‘Title One’; Baines, T S, F Gump and J M Kay, ‘Title Two’.
..[1] See reference 1, Baines et al., ‘Title One’.
>>[2] See reference 1, Baines et al., ‘Title Two’.