Chicago styles: no year in bibliography

mjgreen

I'm writing to a report a problem with several of the Chicago styles and citeproc-hs. The year is getting left out bibliography entries.

Example:

* file.md: Some text.[@Author:2013fk]

* bib_file.bib: @article{Author:2013fk, Author = {Author, Ann}, Journal = {Journal of Testing}, Pages = {23--47}, Title = {This is a test}, Volume = {80}, Year = {2013}}

* expected bibliography output: Author, Ann. “This Is a Test.” {\em Journal of Testing} 80 (2013): 23--47.

* actual bibliography output: Author, Ann. “This Is a Test.” {\em Journal of Testing} 80:
23--47.

This happens for me with chicago-note-biblio-no-ibid.csl. Another user reported a similar problem with chicago-fullnote-bibliography.csl [1]

I tested the same csl file with zotero and got the expected results. So I submitted a bug report for citeproc-hs.

However, the citeproc-hs developer said he was quite certain that the problem lies with the csl file.

We discovered that citeproc-hs produces the expected results if we used a copy of chicago-note-biblio-no-ibid.csl from January 2012. (I think that's at least partly why he thinks the problem lies with the csl files and not citeproc-hs.)

I know this is a zotero forum and my problem is with citeproc-hs rather than zotero (which gets the expected results).

But I can't find any other place to report possible problems with csl files. Please accept my apologies if there is a more appropriate forum that I missed.

Thank you!

[1] http://superuser.com/questions/548801/fixing-a-csl-file-that-fails-to-print-the-date-correctly-in-pandoc

adamsmith

Reporting CSL problems is fine here, I don't quite understand why Andrea thinks this is a problem of the style. It's a valid CSL file. What happens in the style is that there are a couple of nested macro calls and maybe citeproc-hs chokes on that, but it shouldn't. Specifically:
chicago (Full Note, Bibliography), ie. the style you use in your example you link to:

In the bibliography it calls on the macro
"issue-join-with-space"
https://github.com/citation-style-language/styles/blob/master/chicago-fullnote-bibliography.csl#L1034

That macro calls, for journal articles and legal cases, on the macro "issue"
https://github.com/citation-style-language/styles/blob/master/chicago-fullnote-bibliography.csl#L793

Which in turn calls on the macro "issued" enclosed in parentheses:
https://github.com/citation-style-language/styles/blob/master/chicago-fullnote-bibliography.csl#L822

That macro prints the entire date for journal articles:
with <date variable="issued" form="text"/>
https://github.com/citation-style-language/styles/blob/master/chicago-fullnote-bibliography.csl#L585

You can point Andrea here or tell him to ask on the xbiblio list, but the current version of the CMoS style(s) on the repository is correct and valid csl and all csl implementation should render them correctly.

adamsmith

To be clear, the style was significantly rewritten on May 8th 2012
https://github.com/citation-style-language/styles/commit/05419acabb9fe546109652a19eefdf88f22b386c
and the earlier versions likely work with citeproc-hs (though they may have other errors), but again, this is clearly a citeproc-hs bug -
in general, Zotero, because it's tested so intensely both by the sheer amount of users and by automated tests on citeproc-js, serves as a pretty useful reference implementation: If something looks right in Zotero it almost certainly is correct in the style.

mjgreen

I sent the problem back to the citeproc-hs developers. Should anyone else find this and want to follow up, it's issue 69. [1]

Thank you!

[1] http://code.google.com/p/citeproc-hs/issues/detail?id=69

andrea.rossato

> That macro calls, for journal articles and legal cases, on the macro "issue"

Adam, this style is bugged. According to the CSL specification:[1]

«The cs:if and cs:else-if elements may carry the match attribute to control the testing logic, with allowed values:

"all" - (default), element only tests "true" when all conditions test "true" for all given test values
"any" - element tests "true" when any condition tests "true" for any given test value
"none" - element only tests "true" when none of the conditions test "true" for any given test value»

This means that:

<macro name="issue-join-with-space">
<choose>
<if type="article-journal legal_case">
....

will evaluate true only if the reference is *both* an "article-journal" *and* a "legal_case" and *not* if the reference is an "article-journal" *or* a "legal_case".

What the style means is:


<if type="article-journal legal_case" match="any">


If this is true -- and I admit that I could be wrong in reading the specification, even though this doesn't seem to be the case -- that leads me to a problem I've already risen withing the xbiblio community: the fact that a too forgiving reference implementation like citeproc-js is creating huge problems to all other implementations.[2]

The fact that citeproc-js is producing a correct result out of a bugged style is damaging CSL. And makes me waste a huge amount of time.

When I rose this problem Frank had a bad reaction, and I felt bad about it. Still I hope you'll understand that bugged styles producing good results represent a problem for the CSL community as a whole.

Best,
Andrea

[1] http://citationstyles.org/downloads/specification-csl10-20100530.html#choose and http://citationstyles.org/downloads/specification.html#choose

[2] http://sourceforge.net/mailarchive/message.php?msg_id=26670885

adamsmith

you're right. I'll fix this, sorry.

Rintze

We might want to check for styles that use the "type" conditional with two or more item types, and a) without the "match" attribute, or b) with the "match" attribute set to "all". I have no clue if this issue is widespread.

Related, Frank recently opened an issue to discuss the behavior of "match" in the context of the "type" conditional: https://github.com/citation-style-language/schema/issues/108

mjgreen

For the record, this solves the problem, at least for my minimal example.

1. CSL file: chicago-note-biblio-no-ibid, updated 2012-10-25T21:15:26+00:00

2. Change line 794

from this

<if type="article-journal legal_case">

to this

<if type="article-journal legal_case" match="any">

There we have it. Thanks to everyone.

fbennett

Andrea,

Thanks for raising this. Please don't worry about our earlier discussion (about the separate issue of space suppression). I myself regretted my over-reaction on that occasion. In fact, the current Chicago Fullnote implementation has been refactored following your suggestions. I put in that work as a peace offering: I hope you will accept it, as my apology in code.

I am startled by your pointer to the spec on cs:choose. You are absolutely right, of course. The specification clearly requires "all" as default, and citeproc-js defaults to "any". This is not a matter of citeproc-js being forgiving, but of it being wrong. This likely impacts the behaviour of other styles as well, and needs to be addressed -- and soon. Perhaps we can continue the discussion on xbiblio-devel?

Again, thank you for bringing this up, and more generally for the clarity of your work on citeproc-hs.

adamsmith

(FWIW I was generally aware of the specs on this even though I overlooked it in CMoS, so for the styles I coded - unless I overlooked something - match="any" should generally be specified).

Rintze

I wrote a Python script (https://github.com/citation-style-language/utilities/blob/master/csl-reindenting-and-match-fix.py) to fix this issue. Many styles were afflicted: https://github.com/citation-style-language/styles/commit/b55a9c1704b74a35e9aa522dc4e67dc632146781

It's bedtime here now, but I'll post a note to the xbiblio list tomorrow to bring everybody up to date. Andrea, thanks for getting to the bottom of this.

@adamsmith, there is one case I didn't know how to fix. It's https://github.com/citation-style-language/styles/blob/master/harvard-university-of-abertay-dundee.csl#L131 . Can we drop one of the item types, or should we have a nested conditional?

adamsmith

I don't know, it's not my style & it was submitted by a Mendeley user. Technically it's possible that both these item types are needed - and with a quick look at their guide it should also include webpage, so I say we use a nested conditional.

fbennett

Why not just set match="any" there?

fbennett

Oh, I see. You could get "viewed 1 Apr. 2000" without a URL. That's not particularly related to the any/all default issue -- looks like it'll need a nested conditional.

adamsmith

I fixed the Harvard UAD with a nested conditional

Rintze

The xbiblio discussion related to this issue can be found at http://xbiblio-devel.2463403.n2.nabble.com/Multiple-item-quot-type-quot-conditionals-with-match-quot-all-quot-td7578405.html