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?

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

Reply via email to