Draft BNF available

CSL Development
1

So EDTF is starting to get much more concrete. Would be nice if we
could switch to this, or a subset of it, as primary CSL input date
format soon.---------- Forwarded message ----------
From: Denenberg, Ray rden@loc.gov
Date: Thu, Mar 31, 2011 at 9:33 AM
Subject: Draft BNF available
To: DATETIME@listserv.loc.gov

A preliminary draft BNF is at:
http://www.loc.gov/standards/datetime/bnf.html

–Ray

2

So EDTF is starting to get much more concrete. Would be nice if we
could switch to this, or a subset of it, as primary CSL input date
format soon.

I think the parser embedded in citeproc-js can already parse this
syntax, for ordinary dates, date intervals, and dates BCE. It would be
good to have some sample dates data to work with, and test fixtures
based on it. The test data and fixture that I used to build the
citeproc-js parser are in the source archive, if anyone wants to work
on this.

Frank

3

Is this the file you mentioned? Or are there additional tests?

https://bitbucket.org/fbennett/citeproc-js/src/dab133efd75a/tests/citeproc-js/dateparse.js

Would you need tests like this or rather citeproc-tests with a dedicated CSL style that outputs dates (to verify that parsing of input was successful)? I’ve previously set up fixtures using the material on the EDTF page. For instance, this file includes the ISO8601 interval examples:

I’ll gladly convert the fixtures to a format that’s is useful to you, but first it ought to be specified whether or not all the EDTF features (or which subset) should be supported by CSL.

Sylvester

4

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

So EDTF is starting to get much more concrete. Would be nice if we
could switch to this, or a subset of it, as primary CSL input date
format soon.

I think the parser embedded in citeproc-js can already parse this
syntax, for ordinary dates, date intervals, and dates BCE. It would be
good to have some sample dates data to work with, and test fixtures
based on it. The test data and fixture that I used to build the
citeproc-js parser are in the source archive, if anyone wants to work
on this.

Is this the file you mentioned? Or are there additional tests?

https://bitbucket.org/fbennett/citeproc-js/src/dab133efd75a/tests/citeproc-js/dateparse.js

That’s all there is to it. There is a grinder in the ./tools directory
that generates the json, and the json is run via the ./test.py script
using DOH.

Would you need tests like this or rather citeproc-tests with a dedicated CSL style that outputs dates (to verify that parsing of input was successful)? I’ve previously set up fixtures using the material on the EDTF page. For instance, this file includes the ISO8601 interval examples:

edtf-ruby/features/parser/intervals.feature at main · inukshuk/edtf-ruby · GitHub

If the plain text format is easier, it can be ground into the json
format in the same way.

I’ll gladly convert the fixtures to a format that’s is useful to you, but first it ought to be specified whether or not all the EDTF features (or which subset) should be supported by CSL.

Indeed. I think this brings us to that question: what gets left out?

5

Just to be clear, EDTF isn’t final yet. I’m just pointing out that’s
it’s getting closer. By “soon” I mean sometime, hopefully, in the next
few months.

You may or may not want to adjust accordingly.

So a test parser that we can use to provide feedback to the EDTF
group, and then later build on, might be an idea.

Bruce

6

Just to be clear, EDTF isn’t final yet. I’m just pointing out that’s
it’s getting closer. By “soon” I mean sometime, hopefully, in the next
few months.

You may or may not want to adjust accordingly.

So a test parser that we can use to provide feedback to the EDTF
group, and then later build on, might be an idea.

One step ahead of you.

http://gsl-nagoya-u.net/http/pub/citeproc-doc.html#date-parser

It ships with citeproc-js, but it’s a standalone JS module. The API is
documented in the processor manual.

The code is there if anyone wants to pick it up and run with it.

Frank