On Fri, May 20, 2011 at 4:38 AM, Bruce D'Arcus <[email protected]> wrote: > 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) ... > > On Mon, Nov 15, 2010 at 4:42 PM, Frank Bennett <[email protected]> wrote: >> On Tue, Nov 16, 2010 at 6:02 AM, Bruce D'Arcus <[email protected]> wrote: >>> On Mon, Nov 15, 2010 at 3:46 PM, Frank Bennett <[email protected]> >>> wrote: >>>> 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: >> >> 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 > > Bruce > > ------------------------------------------------------------------------------ > What Every C/C++ and Fortran developer Should Know! > Read this article and learn how Intel has extended the reach of its > next-generation tools to help Windows* and Linux* C/C++ and Fortran > developers boost performance applications - including clusters. > http://p.sf.net/sfu/intel-dev2devmay > _______________________________________________ > xbiblio-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/xbiblio-devel > ------------------------------------------------------------------------------ What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay _______________________________________________ xbiblio-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
