# multiple disambiguate="true" conditionals

**URL:** <https://discourse.citationstyles.org/t/multiple-disambiguate-true-conditionals/1169>\
**Category:** CSL Development\
**Created:** [April 15, 2013, 10:29pm UTC](https://discourse.citationstyles.org/t/multiple-disambiguate-true-conditionals/1169 "2013-04-15T22:29:09Z")\
**Posts on this page:** 11\
**Page:** 1

<div class="post-metadata">

**Author:** ![Sebastian\_Karcher](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.citationstyles.org/sebastian_karcher/32/176_2.png) [@Sebastian\_Karcher](https://discourse.citationstyles.org/u/Sebastian_Karcher)\
**Post date:** [April 15, 2013, 10:29pm UTC](https://discourse.citationstyles.org/t/multiple-disambiguate-true-conditionals/1169/1 "2013-04-15T22:29:09Z")

</div>

Following situation:  
The MHRA style currently prints only author names in subsequent notes,  
adding title-short when disambiguate evaluates to true. So far that’s  
working great.

Now, some materials - especially interviews and letters - often don’t have  
titles, others - e.g. webpages - may have the same title and author.  
I tried adding issued date with if disambiguate=“true” - but at least in  
Zotero/citerproc-js that means that date _and_ short title are printed  
whenever the authors are the same, which, most of the time, is incorrect.  
Twofold question:

1. Is there a way I’m overlooking that would allow me to add the date only  
if disambiguation by title fails? (obviously I can test for presence of a  
title, but that still doesn’t help when titles are the same).
2. Are the other citeproc implementations behaving the same way as  
citeproc? Or are some evaluating the conditionals sequentially?

code example, where both the title-short and the date-disambiguate macro  
start with  
:

 ... -- Sebastian Karcher Ph.D. Candidate Department of Political Science Northwestern University

---

<div class="post-metadata">

**Author:** ![Frank\_Bennett](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.citationstyles.org/frank_bennett/32/198_2.png) [@Frank\_Bennett](https://discourse.citationstyles.org/u/Frank_Bennett)\
**Post date:** [April 15, 2013, 11:26pm UTC](https://discourse.citationstyles.org/t/multiple-disambiguate-true-conditionals/1169/2 "2013-04-15T23:26:23Z")

</div>

> Following situation:  
> The MHRA style currently prints only author names in subsequent notes,  
> adding title-short when disambiguate evaluates to true. So far that’s  
> working great.
> 
> Now, some materials - especially interviews and letters - often don’t have  
> titles, others - e.g. webpages - may have the same title and author.  
> I tried adding issued date with if disambiguate=“true” - but at least in  
> Zotero/citerproc-js that means that date _and_ short title are printed  
> whenever the authors are the same, which, most of the time, is incorrect.  
> Twofold question:
> 
> 1. Is there a way I’m overlooking that would allow me to add the date only  
> if disambiguation by title fails? (obviously I can test for presence of a  
> title, but that still doesn’t help when titles are the same).
> 2. Are the other citeproc implementations behaving the same way as citeproc?  
> Or are some evaluating the conditionals sequentially?

I was wondering when this issue would come around. 🙂

citeproc-js is currently coded as you describe: it’s all or nothing.  
I’ve wondered about setting up a staged invocation, setting one node  
at a time to “true” until the cite clears or disambiguation fails. It  
would be a neat trick, since it could be done without changes to CSL.

So with Sebastian, I’ll ask: has anyone implemented  
disambiguate=“true” in that way?

---

<div class="post-metadata">

**Author:** ![Charles\_Parnot](https://avatars.discourse-cdn.com/v4/letter/c/57b2e6/32.png) [@Charles\_Parnot](https://discourse.citationstyles.org/u/Charles_Parnot)\
**Post date:** [April 16, 2013, 7:02am UTC](https://discourse.citationstyles.org/t/multiple-disambiguate-true-conditionals/1169/3 "2013-04-16T07:02:53Z")

</div>

The ‘disambiguate’ conditional is not implemented at the moment in Papers.

---

<div class="post-metadata">

**Author:** ![Frank\_Bennett](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.citationstyles.org/frank_bennett/32/198_2.png) [@Frank\_Bennett](https://discourse.citationstyles.org/u/Frank_Bennett)\
**Post date:** [April 17, 2013, 1:31pm UTC](https://discourse.citationstyles.org/t/multiple-disambiguate-true-conditionals/1169/4 "2013-04-17T13:31:03Z")

</div>

I’ve implemented incremental application of disambiguate=“true” in  
citeproc-js (release 1.0.451). There is a test for it here:

[https://bitbucket.org/bdarcus/citeproc-test/src/tip/processor-tests/humans/disambiguate\_IncrementalExtraText.txt?at=default](https://bitbucket.org/bdarcus/citeproc-test/src/tip/processor-tests/humans/disambiguate_IncrementalExtraText.txt?at=default)

Frank

---

<div class="post-metadata">

**Author:** ![andrea\_rossato2](https://avatars.discourse-cdn.com/v4/letter/a/e99b99/32.png) [@andrea\_rossato2](https://discourse.citationstyles.org/u/andrea_rossato2)\
**Post date:** [April 18, 2013, 9:37am UTC](https://discourse.citationstyles.org/t/multiple-disambiguate-true-conditionals/1169/5 "2013-04-18T09:37:13Z")

</div>

Sebastian Karcher \<@Sebastian\_Karcher\> writes:

> Following situation:  
> The MHRA style currently prints only author names in subsequent notes,  
> adding title-short when disambiguate evaluates to  
> true. So far that’s working great.
> 
> Now, some materials - especially interviews and letters - often don’t  
> have titles, others - e.g. webpages - may have the  
> same title and author.  
> I tried adding issued date with if disambiguate=“true” - but at least  
> in Zotero/citerproc-js that means that date _and_  
> short title are printed whenever the authors are the same, which, most  
> of the time, is incorrect. Twofold question:
> 
> 1. Is there a way I’m overlooking that would allow me to add the date  
> only if disambiguation by title fails? (obviously I  
> can test for presence of a title, but that still doesn’t help when  
> titles are the same).

No, but the specification is quite clear on this: if evaluating a  
citation with disambiguate=“true” does not lead to disambiguation the  
ambiguous citation is rendered as it stands.

Incremental application of the conditional may be added to the  
specification even though I’m not sure I like Frank’s implementation and  
the proposed test.

> 1. Are the other citeproc implementations behaving the same way as  
> citeproc? Or are some evaluating the conditionals  
> sequentially?

The Haskell implementation only tries the conditional once.

Best,  
Andrea

---

<div class="post-metadata">

**Author:** ![andrea\_rossato2](https://avatars.discourse-cdn.com/v4/letter/a/e99b99/32.png) [@andrea\_rossato2](https://discourse.citationstyles.org/u/andrea_rossato2)\
**Post date:** [April 18, 2013, 9:48am UTC](https://discourse.citationstyles.org/t/multiple-disambiguate-true-conditionals/1169/6 "2013-04-18T09:48:38Z")

</div>

Frank Bennett \<@Frank\_Bennett\> writes:

> I’ve implemented incremental application of disambiguate=“true” in  
> citeproc-js (release 1.0.451). There is a test for it here:
> 
> [https://bitbucket.org/bdarcus/citeproc-test/src/tip/processor-tests/humans/disambiguate\_IncrementalExtraText.txt?at=default](https://bitbucket.org/bdarcus/citeproc-test/src/tip/processor-tests/humans/disambiguate_IncrementalExtraText.txt?at=default)

Actually I’m not sure I like this approach because I find it a bit  
confusing. If “disambiguate” is “true” then it should always evaluate to  
“true” and so both the title and the edition should be printed. The  
example is not confusing because all the disambiguate conditionals are  
grouped together. When coded in macros their order of occurrence may be  
more difficult to understand and predict, thus becoming a source of  
possible bugs.

I understand that my perception may be due to different coding cultures  
– Haskell is a purely functional language and the value of a variable  
is not going to change depending on the context --, still I wanted to  
share my perspective.

Andrea

---

<div class="post-metadata">

**Author:** ![Frank\_Bennett](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.citationstyles.org/frank_bennett/32/198_2.png) [@Frank\_Bennett](https://discourse.citationstyles.org/u/Frank_Bennett)\
**Post date:** [April 18, 2013, 11:33am UTC](https://discourse.citationstyles.org/t/multiple-disambiguate-true-conditionals/1169/7 "2013-04-18T11:33:02Z")

</div>

> Frank Bennett \<@Frank\_Bennett\> writes:
> 
> > I’ve implemented incremental application of disambiguate=“true” in  
> > citeproc-js (release 1.0.451). There is a test for it here:
> > 
> > [https://bitbucket.org/bdarcus/citeproc-test/src/tip/processor-tests/humans/disambiguate\_IncrementalExtraText.txt?at=default](https://bitbucket.org/bdarcus/citeproc-test/src/tip/processor-tests/humans/disambiguate_IncrementalExtraText.txt?at=default)
> 
> Actually I’m not sure I like this approach because I find it a bit  
> confusing. If “disambiguate” is “true” then it should always evaluate to  
> “true” and so both the title and the edition should be printed. The  
> example is not confusing because all the disambiguate conditionals are  
> grouped together. When coded in macros their order of occurrence may be  
> more difficult to understand and predict, thus becoming a source of  
> possible bugs.
> 
> I understand that my perception may be due to different coding cultures  
> – Haskell is a purely functional language and the value of a variable  
> is not going to change depending on the context --, still I wanted to  
> share my perspective.
> 
> Andrea

No, you’re right. This adds elements incrementally from the  
first-occurring to the last (in rendering order), and it would be good  
to have more control over the sequence. That would involve some  
changes to the specification, but could be done.

Shall I move that test out of the suite, pending further discussion of  
the approach? There’s no urgency, and it would be good to explore the  
possibilities further.

---

<div class="post-metadata">

**Author:** ![Charles\_Parnot](https://avatars.discourse-cdn.com/v4/letter/c/57b2e6/32.png) [@Charles\_Parnot](https://discourse.citationstyles.org/u/Charles_Parnot)\
**Post date:** [April 18, 2013, 11:40am UTC](https://discourse.citationstyles.org/t/multiple-disambiguate-true-conditionals/1169/8 "2013-04-18T11:40:45Z")

</div>

I agree that relying on the rendering order for incremental disambiguation is not a great solution.

Note that there is one situation where we have something similar, which is the element, that tries each child in order. In a way, that might be a saner solution, if not as flexible. For more complex situations, the would have to be quite high up in the rendering tree, and would look something like this:

```
<if disambiguate="true">
	<text macro="disambiguate1" />
	<text macro="disambiguate2" />
	<text macro="disambiguate3" />
	<text macro="disambiguate4" />
</if>
<else>
	<text macro="normal" />
</else>

```

Charles

---

<div class="post-metadata">

**Author:** ![Frank\_Bennett](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.citationstyles.org/frank_bennett/32/198_2.png) [@Frank\_Bennett](https://discourse.citationstyles.org/u/Frank_Bennett)\
**Post date:** [April 18, 2013, 12:01pm UTC](https://discourse.citationstyles.org/t/multiple-disambiguate-true-conditionals/1169/9 "2013-04-18T12:01:50Z")

</div>

> I agree that relying on the rendering order for incremental disambiguation is not a great solution.
> 
> Note that there is one situation where we have something similar, which is the element, that tries each child in order. In a way, that might be a saner solution, if not as flexible. For more complex situations, the would have to be quite high up in the rendering tree, and would look something like this:
> 
> ```
> <if disambiguate="true">
> <text macro="disambiguate1" />
> <text macro="disambiguate2" />
> <text macro="disambiguate3" />
> <text macro="disambiguate4" />
> </if>
> <else>
> <text macro="normal" />
> </else>
> 
> ```
> 
> Charles

In that case, how would you control the placement of the incremental  
elements? Would the idea be for each one to encapsulate an entire  
citation, separately constructed in the respective macros? (I might be  
missing something but) if so, it seems like the style code might be  
kind of tricky to maintain.

---

<div class="post-metadata">

**Author:** ![Charles\_Parnot](https://avatars.discourse-cdn.com/v4/letter/c/57b2e6/32.png) [@Charles\_Parnot](https://discourse.citationstyles.org/u/Charles_Parnot)\
**Post date:** [April 18, 2013, 12:08pm UTC](https://discourse.citationstyles.org/t/multiple-disambiguate-true-conditionals/1169/10 "2013-04-18T12:08:32Z")

</div>

> > I agree that relying on the rendering order for incremental disambiguation is not a great solution.
> > 
> > Note that there is one situation where we have something similar, which is the element, that tries each child in order. In a way, that might be a saner solution, if not as flexible. For more complex situations, the would have to be quite high up in the rendering tree, and would look something like this:
> > 
> > ```
> > <if disambiguate="true">
> > <text macro="disambiguate1" />
> > <text macro="disambiguate2" />
> > <text macro="disambiguate3" />
> > <text macro="disambiguate4" />
> > </if>
> > <else>
> > <text macro="normal" />
> > </else>
> > 
> > ```
> > 
> > Charles
> 
> In that case, how would you control the placement of the incremental  
> elements? Would the idea be for each one to encapsulate an entire  
> citation, separately constructed in the respective macros? (I might be  
> missing something but) if so, it seems like the style code might be  
> kind of tricky to maintain.

Yes, that’s what I meant by needing the construct to be quite high in the rendering tree. That would of course only be necessary for more complicated cases where ading one disambiguation somewhere in the rendering tree is not enough.

To be clear, I am not saying this is ideal, nor is it based on any insight in creating styles. I was just thinking out loud, and it might very well be more flexible disambiguation is needed too often for such a solution to be practical.

The other downside of this is that it becomes very hard to specify the behavior when the style contains multiple of that nature.

So probably not a very good idea 🙂

Charles

---

<div class="post-metadata">

**Author:** ![Frank\_Bennett](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.citationstyles.org/frank_bennett/32/198_2.png) [@Frank\_Bennett](https://discourse.citationstyles.org/u/Frank_Bennett)\
**Post date:** [April 18, 2013, 12:17pm UTC](https://discourse.citationstyles.org/t/multiple-disambiguate-true-conditionals/1169/11 "2013-04-18T12:17:17Z")

</div>

> > > I agree that relying on the rendering order for incremental disambiguation is not a great solution.
> > > 
> > > Note that there is one situation where we have something similar, which is the element, that tries each child in order. In a way, that might be a saner solution, if not as flexible. For more complex situations, the would have to be quite high up in the rendering tree, and would look something like this:
> > > 
> > > ```
> > > <if disambiguate="true">
> > > <text macro="disambiguate1" />
> > > <text macro="disambiguate2" />
> > > <text macro="disambiguate3" />
> > > <text macro="disambiguate4" />
> > > </if>
> > > <else>
> > > <text macro="normal" />
> > > </else>
> > > 
> > > ```
> > > 
> > > Charles
> > 
> > In that case, how would you control the placement of the incremental  
> > elements? Would the idea be for each one to encapsulate an entire  
> > citation, separately constructed in the respective macros? (I might be  
> > missing something but) if so, it seems like the style code might be  
> > kind of tricky to maintain.
> 
> Yes, that’s what I meant by needing the construct to be quite high in the rendering tree. That would of course only be necessary for more complicated cases where ading one disambiguation somewhere in the rendering tree is not enough.
> 
> To be clear, I am not saying this is ideal, nor is it based on any insight in creating styles. I was just thinking out loud, and it might very well be more flexible disambiguation is needed too often for such a solution to be practical.
> 
> The other downside of this is that it becomes very hard to specify the behavior when the style contains multiple of that nature.
> 
> So probably not a very good idea 🙂
> 
> Charles

The more ideas, the better!