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
The example comes from here:
http://bitbucket.org/fbennett/citeproc-js/src/tip/demo/sampledata.html
Andrea
It’s described here:
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.
Bruce
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
It’s described here:
gsl-nagoya-u.net - This website is for sale! - gsl nagoya u Resources and Information.
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
It would be nice to offer a more elegant solution sometime soon.
It’s described here:
gsl-nagoya-u.net - This website is for sale! - gsl nagoya u Resources and Information.
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:
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
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
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
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 - This website is for sale! - gsl nagoya u Resources and Information.
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
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