good point. But the same result with the following code:


<choose>
<if disambiguate="false">
<text value="disambiguate value is false"/>
</if>
<else>
<text value="disambiguate value neither true or false"/>
</else>
</choose>


Still, I get both "disambiguate value is false" and "disambiguate value neither true or false" together for all subsequent citations. As I noted in another thread (https://forums.zotero.org/discussion/34475/how-is-the-disambiguate-boolean-determined), due to this errant behavior, I can't disambiguate.

@fbennett,

Yes, I think my style is probably off. I applied a different style (than the one I wrote) which also incorporates disambiguate="true", and it works fine. Is there an option within CSL that may be hindering the proper operation of "disambiguate"?

Actually the snippet I posted above came from an actual macro:


<macro name="foreign-secondary-subsequent">
<group delimiter=", ">
<choose>
<if type="book">
<text macro="foreign-author-short" />
</if>
<else-if type="webpage" variable="issued" match="all">
<text macro="foreign-author-short" />
</else-if>
<else>
<text macro="foreign-author-short"/>
</else>
</choose>
<choose>
<if disambiguate="true">
<text macro="foreign-short-title" text-case="title"/>
</if>
** rest is deleted **


The disambiguate="true" in the code above doesn't work.

yes, at fbennett.github.io/csl-validator.js. No problem.

https://gist.github.com/anonymous/8c5498eab5afbd031928

Hang in there. It's Saturday here, and we''re past the main pressures of term. I'll take a look and we'll get to the bottom of it.

The CSL-m validator reports many syntax errors for the style code posted to the gist above. Here is a version with the more serious errors fixed: https://gist.github.com/fbennett/8606502

The most glaring errors were an apostrophe character between two XML nodes, and a use of punctuation-in-quote on a cs:name node. Both of those are pretty serious, and could well adversely affect the operation of the processor. The various syntax errors are almost certainly the cause of the disambiguation failures you are seeing.

There is a lot of new code in there -- the style is over 4,000 lines long, over a thousand lines longer than the largest MLZ styles. The size itself isn't a problem for the processor, but the more code there is, the harder it becomes to maintain the style. You might want to take a careful look and see whether there isn't potential for consolidating portions of the code to make it more compact.

Note that the code I've posted above still doesn't validate. The code in the style makes extensive use of illegal space characters on affixes. Removing them will take some effort, but they'll need to be removed for the style to fully validate against the CSL-m schema. Trailing spaces on suffixes and leading spaces on prefixes are not permitted in CSL-m syntax outside of cs:date and cs:name nodes: ordinary spaces can only be supplied through a group delimiter. I've imposed that constraint on the syntax because elements with hard-coded spaces can easily produce broken formatting when variables are missing from the input.

The disambiguate="true" conditionals may work correctly in the code I've posted above, but it would be a really good idea to go through the code to weed out the affixes and simplify the macros where possible.

I had no idea spaces are not allowed in suffixes and prefixes.

Btw. - that's only the case for csl-m. Spaces in affixes are allowed in regular CSL and I think they'll likely remain allowed.

Spaces in affixes are allowed in regular CSL and I think they'll likely remain allowed.

♫ You say tomato and I say tomahto ... ♫

:-)

Oops.. Do you use a different test engine than http://fbennett.github.io/csl-validator.js/ ? Neither the CSL-m validator nor chrome://zotero/content/tools/csledit.xul reported any error with the style.

Ok, this has worked for me.


<else-if>
<conditions match="all">
<condition position="subsequent"/>
<condition position="ibid" match="none"/>
</conditions>
<text macro="ko-secondary-subsequent"/>
</else-if>
<else-if type="book" >
<text macro="ko-book"/>
</else-if>
<else-if type="chapter">
<text macro="ko-chapter"/>
</else-if>
<else-if type="article-journal">
<text macro="ko-periodical"/>
</else-if>


(The disambiguation is done within macro="ko-secondary-subsequent".)

Previously, the ibid/ibid-with-locator/subsequent tri-furcation was built into each of ko-book, ko-chapter and ko-periodican, and macro="ko-secondary-subsequent" would be called upon by each if the citation was a subsequent one.

In this version, as you can see, I check position="subsequent" first. I have no idea why this routine disambiguates, whereas the previous one didn't.