Date form-attribute numeric

tillheilmann

What is the expected output format of this construct?

<date variable="issued" form="numeric">
<date-part name="day"/>
<date-part name="month"/>
<date-part name="year"/>
</date>

Using this code, Zotero renders dates like this: '19.9.1999'. And that's what I would expect. Except pandoc-citeproc / citeproc-hs will render the month in long form, i.e. '19.September.1999'. So, for getting it right with pandoc, I have to use this construct:

<date variable="issued">
<date-part name="day" suffix="."/>
<date-part name="month" form="numeric" suffix="."/>
<date-part name="year"/>
</date>

I'm asking to this with regard to the discussion in https://groups.google.com/forum/#!topic/pandoc-discuss/WgbN7tTcITQ.

zuphilip

The CSL specification should give us the answer here: If you use "numeric" or "text" as value for form, then the localized version are used, e.g. numeric for de-DE: 19.09.1999. Alternatively, you can create an individual appearance of the date with the date-parts elements. Why are you using both? Just try
<date variable="issued" form="numeric"/> Or alternatively your other construct if you don't want the leading zeros. Does that work the same in zotero and pandoc?

tillheilmann

That's the point: It is _not_ working the same in Zotero and pandoc. The minimal CSL below will render dates like this

'19.9.1999'

in Zotero, and like this

'19.September.1999'

in pandoc. So I have to write

<date prefix=", " variable="issued">
<date-part name="day" suffix="."/>
<date-part name="month" form="numeric" suffix="."/>
<date-part name="year"/>
</date>

instead of

<date prefix=", " variable="issued" form="numeric">
<date-part name="day"/>
<date-part name="month"/>
<date-part name="year"/>
</date>

to get it working the same way in both Zotero and pandoc.

<?xml version="1.0" encoding="utf-8"?>
<style xmlns="http://purl.org/net/xbiblio/csl" version="1.0" class="note"
default-locale="de-DE" demote-non-dropping-particle="sort-only">
<info>
<title>Test</title>
<id>http://www.zotero.org/styles/test</id>;
<link href="http://www.tillheilmann.info/english.php"
rel="documentation"/>
<author>
<name>Till A. Heilmann</name>
<email>maail@tillheilmann.info</email>
<uri>http://www.tillheilmann.info</uri>;
</author>
<category citation-format="note"/>
<category field="humanities"/>
<summary>Test</summary>
<updated>2014-09-13T22:01:31+00:00</updated>
<rights license="http://creativecommons.org/licenses/by-sa/3.0/">This
work is licensed under a Creative Commons Attribution-ShareAlike 3.0
License</rights>
</info>
<citation>
<layout>
<names variable="author"></names>
<text prefix=", " variable="title"/>
<date prefix=", " variable="issued" form="numeric">
<date-part name="day"/>
<date-part name="month"/>
<date-part name="year"/>
</date>
</layout>
</citation>
</style>

zuphilip

Why are you using the form argument AND the date-part elements together?

tillheilmann

Ah! I'm sorry I misunderstood you: It never occurred to me that you can just drop the date-part elements if you don't want to format them separately. Now, of course, (i.e. without the date-part elements) both Zotero and pandoc work the same. Thanks!

Rintze

Your original example is not invalid CSL, though. I suspect citeproc-js and pandoc-citeproc just have a slightly different understanding of the text:

"Secondly, [a localizing] cs:date may have one or more cs:date-part child elements (see Date-part). The attributes set on these elements override those specified for the localized date formats"

For the example below, citeproc-js presumably recognizes that no attributes are set on the cs:date-part elements, so it uses the original "numeric" localized date form. Whereas it looks like pandoc-citeproc resets the value of the "form" attribute to its default value because it's not defined. I think citeproc-js follows the preferred interpretation, so this should probably be reported to pandoc-citeproc as a bug.


<date variable="issued" form="numeric">
<date-part name="day"/>
<date-part name="month"/>
<date-part name="year"/>
</date>


tillheilmann

Okay, will try to do that (bug report). Thanks!