# json representation?

**URL:** <https://discourse.citationstyles.org/t/json-representation/918>\
**Category:** CSL Development\
**Created:** [November 15, 2010, 2:55pm UTC](https://discourse.citationstyles.org/t/json-representation/918 "2010-11-15T14:55:44Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![Bruce\_D\_Arcus1](https://avatars.discourse-cdn.com/v4/letter/b/4bbf92/32.png) [@Bruce\_D\_Arcus1](https://discourse.citationstyles.org/u/Bruce_D_Arcus1)\
**Post date:** [November 15, 2010, 2:55pm UTC](https://discourse.citationstyles.org/t/json-representation/918/1 "2010-11-15T14:55:44Z")

</div>

So where are we on a common json representation of input data?

I ask because I note Andrea posted a note on the pandoc list with an  
example json file with:

```
	"issued": {
		"date-parts":[
			[2005, 11, 22]
		]
	},

```

While I realize it’s a more direct representation of the CSL model,  
it’s rather complex. Just wondering where that representation came  
from, and why we can’t use standard ISO 8601 date-time format:

```
	"issued": "2005-11-22"

```

Bruce

---

<div class="post-metadata">

**Author:** ![Andrea\_Rossato1](https://avatars.discourse-cdn.com/v4/letter/a/e47774/32.png) [@Andrea\_Rossato1](https://discourse.citationstyles.org/u/Andrea_Rossato1)\
**Post date:** [November 15, 2010, 6:08pm UTC](https://discourse.citationstyles.org/t/json-representation/918/2 "2010-11-15T18:08:15Z")

</div>

The example comes from here:  
[http://bitbucket.org/fbennett/citeproc-js/src/tip/demo/sampledata.html](http://bitbucket.org/fbennett/citeproc-js/src/tip/demo/sampledata.html)

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:** [November 15, 2010, 8:46pm UTC](https://discourse.citationstyles.org/t/json-representation/918/3 "2010-11-15T20:46:56Z")

</div>

It’s described here:

[http://gsl-nagoya-u.net/http/pub/citeproc-doc.html#dates](http://gsl-nagoya-u.net/http/pub/citeproc-doc.html#dates)

If the processor should accept data as EDTF, please give us specific  
guidance on what portions of EDTF are to be supported, and how the  
various permutations are to be controlled for rendering in CSL. When  
pandoc, Zotero and Mendeley agree on a new form of data input and any  
extensions to CSL that you require, we can easily adapt the  
processors.

---

<div class="post-metadata">

**Author:** ![Bruce\_D\_Arcus1](https://avatars.discourse-cdn.com/v4/letter/b/4bbf92/32.png) [@Bruce\_D\_Arcus1](https://discourse.citationstyles.org/u/Bruce_D_Arcus1)\
**Post date:** [November 15, 2010, 9:02pm UTC](https://discourse.citationstyles.org/t/json-representation/918/4 "2010-11-15T21:02:25Z")

</div>

My general opinion is we shouldn’t make the 99% of cases that  
correspond to standard ISO date formats more complex to accommodate  
the 1% that don’t.

But maybe we can come back to this when EDTF is a little less of a  
moving target. E.g. I’d like at some point to simply say “The CSL  
standard date input format is EDTF.” That should solve our syntax and  
model issues simultaneously, and also be compatible with ISO 8601. In  
that case, we wouldn’t have to answer the questions you ask, and would  
just defer to EDTF.

Bruce

---

<div class="post-metadata">

**Author:** ![Bruce\_D\_Arcus1](https://avatars.discourse-cdn.com/v4/letter/b/4bbf92/32.png) [@Bruce\_D\_Arcus1](https://discourse.citationstyles.org/u/Bruce_D_Arcus1)\
**Post date:** [November 15, 2010, 9:08pm UTC](https://discourse.citationstyles.org/t/json-representation/918/5 "2010-11-15T21:08:38Z")

</div>

Well, OK …On Mon, Nov 15, 2010 at 4:02 PM, Bruce D’Arcus \<@Bruce\_D\_Arcus1\> wrote:

> E.g. I’d like at some point to simply say “The CSL  
> standard date input format is EDTF.”

… maybe more like “a subset of EDTF.”

🙂

Bruce

---

<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:** [November 15, 2010, 9:42pm UTC](https://discourse.citationstyles.org/t/json-representation/918/6 "2010-11-15T21:42:14Z")

</div>

> > It’s described here:
> > 
> > [gsl-nagoya-u.net&nbsp;-&nbsp;This website is for sale!&nbsp;-&nbsp;gsl nagoya u Resources and Information.](http://gsl-nagoya-u.net/http/pub/citeproc-doc.html#dates)
> > 
> > If the processor should accept data as EDTF, please give us specific  
> > guidance on what portions of EDTF are to be supported, and how the  
> > various permutations are to be controlled for rendering in CSL. When  
> > pandoc, Zotero and Mendeley agree on a new form of data input and any  
> > extensions to CSL that you require, we can easily adapt the  
> > processors.
> 
> My general opinion is we shouldn’t make the 99% of cases that  
> correspond to standard ISO date formats more complex to accommodate  
> the 1% that don’t.
> 
> But maybe we can come back to this when EDTF is a little less of a  
> moving target. E.g. I’d like at some point to simply say “The CSL  
> standard date input format is EDTF.” That should solve our syntax and  
> model issues simultaneously, and also be compatible with ISO 8601. In  
> that case, we wouldn’t have to answer the questions you ask, and would  
> just defer to EDTF.

That sounds very sensible.

The main point is that the conversation at this stage needs to be  
among CSL language designers (esp. yourself and Rintze), CSL style  
authors (esp. adamsmith, MHSmith, noksagt), and CSL-consuming projects  
(esp. pandoc, Zotero and Mendeley). The implementations stand in the  
middle, and can follow suit once the design has been agreed and  
determined by the others; but we can’t move until then.

Can a timeline be set? For the past half-decade, users have been  
handling ranges and dumb strings in one way or another. While I would  
agree that it’s a mixed blessing, we’re kind of lucky that this turns  
out to be possible under Zotero 2.1:

[Better Date Field - Zotero Forums](http://forums.zotero.org/discussion/6111/2/better-date-field/#Item_14)

It would be nice to offer a more elegant solution sometime soon.

---

<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:** [November 15, 2010, 10:51pm UTC](https://discourse.citationstyles.org/t/json-representation/918/7 "2010-11-15T22:51:55Z")

</div>

> > > It’s described here:
> > > 
> > > [gsl-nagoya-u.net&nbsp;-&nbsp;This website is for sale!&nbsp;-&nbsp;gsl nagoya u Resources and Information.](http://gsl-nagoya-u.net/http/pub/citeproc-doc.html#dates)
> > > 
> > > If the processor should accept data as EDTF, please give us specific  
> > > guidance on what portions of EDTF are to be supported, and how the  
> > > various permutations are to be controlled for rendering in CSL. When  
> > > pandoc, Zotero and Mendeley agree on a new form of data input and any  
> > > extensions to CSL that you require, we can easily adapt the  
> > > processors.
> > 
> > My general opinion is we shouldn’t make the 99% of cases that  
> > correspond to standard ISO date formats more complex to accommodate  
> > the 1% that don’t.
> > 
> > But maybe we can come back to this when EDTF is a little less of a  
> > moving target. E.g. I’d like at some point to simply say “The CSL  
> > standard date input format is EDTF.” That should solve our syntax and  
> > model issues simultaneously, and also be compatible with ISO 8601. In  
> > that case, we wouldn’t have to answer the questions you ask, and would  
> > just defer to EDTF.
> 
> That sounds very sensible.
> 
> The main point is that the conversation at this stage needs to be  
> among CSL language designers (esp. yourself and Rintze), CSL style  
> authors (esp. adamsmith, MHSmith, noksagt), and CSL-consuming projects  
> (esp. pandoc, Zotero and Mendeley). The implementations stand in the  
> middle, and can follow suit once the design has been agreed and  
> determined by the others; but we can’t move until then.

A fresh example of the need for dialog on the CSL/style authorship axis:

[French localization (csl 1.0) - Zotero Forums](http://forums.zotero.org/discussion/15085?page=2#Comment_75510)

---

<div class="post-metadata">

**Author:** ![Bruce\_D\_Arcus1](https://avatars.discourse-cdn.com/v4/letter/b/4bbf92/32.png) [@Bruce\_D\_Arcus1](https://discourse.citationstyles.org/u/Bruce_D_Arcus1)\
**Post date:** [May 19, 2011, 7:38pm UTC](https://discourse.citationstyles.org/t/json-representation/918/8 "2011-05-19T19:38:08Z")

</div>

Going back to this date issue in JSON, since I never answered this  
(and am reminded of it again while struggling with this date  
representation) …

> > > It’s described here:
> > > 
> > > [http://gsl-nagoya-u.net/http/pub/citeproc-doc.html#dates](http://gsl-nagoya-u.net/http/pub/citeproc-doc.html#dates)
> > > 
> > > If the processor should accept data as EDTF, please give us specific  
> > > guidance on what portions of EDTF are to be supported, and how the  
> > > various permutations are to be controlled for rendering in CSL. When  
> > > pandoc, Zotero and Mendeley agree on a new form of data input and any  
> > > extensions to CSL that you require, we can easily adapt the  
> > > processors.
> > 
> > My general opinion is we shouldn’t make the 99% of cases that  
> > correspond to standard ISO date formats more complex to accommodate  
> > the 1% that don’t.
> > 
> > But maybe we can come back to this when EDTF is a little less of a  
> > moving target. E.g. I’d like at some point to simply say “The CSL  
> > standard date input format is EDTF.” That should solve our syntax and  
> > model issues simultaneously, and also be compatible with ISO 8601. In  
> > that case, we wouldn’t have to answer the questions you ask, and would  
> > just defer to EDTF.
> 
> That sounds very sensible.
> 
> The main point is that the conversation at this stage needs to be  
> among CSL language designers (esp. yourself and Rintze), CSL style  
> authors (esp. adamsmith, MHSmith, noksagt), and CSL-consuming projects  
> (esp. pandoc, Zotero and Mendeley). The implementations stand in the  
> middle, and can follow suit once the design has been agreed and  
> determined by the others; but we can’t move until then.
> 
> Can a timeline be set? For the past half-decade, users have been  
> handling ranges and dumb strings in one way or another. While I would  
> agree that it’s a mixed blessing, we’re kind of lucky that this turns  
> out to be possible under Zotero 2.1:
> 
> [Better Date Field - Zotero Forums](http://forums.zotero.org/discussion/6111/2/better-date-field/#Item_14)
> 
> It would be nice to offer a more elegant solution sometime soon.

I don’t know about timeline, since it depends a bit on the Library of Congress.

But I believe they’re getting close to settling on the final use cases  
and draft syntax, in ways suitable to testing.

My hope would be that this would allow us to use ISO standard  
date-times for the vast majority of use cases, and defer to EDTF for  
the remainder (circa and questionable dates, seasons, etc.).

How should we proceed, then?

Bruce

---

<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:** [May 19, 2011, 10:14pm UTC](https://discourse.citationstyles.org/t/json-representation/918/9 "2011-05-19T22:14:19Z")

</div>

> Going back to this date issue in JSON, since I never answered this  
> (and am reminded of it again while struggling with this date  
> representation) …
> 
> > > > It’s described here:
> > > > 
> > > > [gsl-nagoya-u.net&nbsp;-&nbsp;This website is for sale!&nbsp;-&nbsp;gsl nagoya u Resources and Information.](http://gsl-nagoya-u.net/http/pub/citeproc-doc.html#dates)
> > > > 
> > > > If the processor should accept data as EDTF, please give us specific  
> > > > guidance on what portions of EDTF are to be supported, and how the  
> > > > various permutations are to be controlled for rendering in CSL. When  
> > > > pandoc, Zotero and Mendeley agree on a new form of data input and any  
> > > > extensions to CSL that you require, we can easily adapt the  
> > > > processors.
> > > 
> > > My general opinion is we shouldn’t make the 99% of cases that  
> > > correspond to standard ISO date formats more complex to accommodate  
> > > the 1% that don’t.
> > > 
> > > But maybe we can come back to this when EDTF is a little less of a  
> > > moving target. E.g. I’d like at some point to simply say “The CSL  
> > > standard date input format is EDTF.” That should solve our syntax and  
> > > model issues simultaneously, and also be compatible with ISO 8601. In  
> > > that case, we wouldn’t have to answer the questions you ask, and would  
> > > just defer to EDTF.
> > 
> > That sounds very sensible.
> > 
> > The main point is that the conversation at this stage needs to be  
> > among CSL language designers (esp. yourself and Rintze), CSL style  
> > authors (esp. adamsmith, MHSmith, noksagt), and CSL-consuming projects  
> > (esp. pandoc, Zotero and Mendeley). The implementations stand in the  
> > middle, and can follow suit once the design has been agreed and  
> > determined by the others; but we can’t move until then.
> > 
> > Can a timeline be set? For the past half-decade, users have been  
> > handling ranges and dumb strings in one way or another. While I would  
> > agree that it’s a mixed blessing, we’re kind of lucky that this turns  
> > out to be possible under Zotero 2.1:
> > 
> > [Better Date Field - Zotero Forums](http://forums.zotero.org/discussion/6111/2/better-date-field/#Item_14)
> > 
> > It would be nice to offer a more elegant solution sometime soon.
> 
> I don’t know about timeline, since it depends a bit on the Library of Congress.
> 
> But I believe they’re getting close to settling on the final use cases  
> and draft syntax, in ways suitable to testing.
> 
> My hope would be that this would allow us to use ISO standard  
> date-times for the vast majority of use cases, and defer to EDTF for  
> the remainder (circa and questionable dates, seasons, etc.).
> 
> How should we proceed, then?

I guess the first step would be a specification that defines the  
subset of EDTF to be used for the forms that are outside of ISO. Then  
I guess the input validation machinery should be extended to cover  
date strings.

Once that’s in hand, assuming valid date string input on a date  
variable, citeproc-js can easily be adjusted to handle it, if it  
doesn’t do that already. It can be made to handle both forms of input,  
so for Zotero, Mendeley, and others using citeproc-js, the transition  
could happen whenever the projects are ready to implement the change.

Shifting the test suite over to the new date syntax can happen  
whenever Andrea, Sylvester and Faolan are ready for it.

Frank