Hi, all,
Jakob Voss has made some sensible proposals for enhancements to date
support over on the citeproc-js tracker, some time back. I’ve just
posted some thoughts on the way forward over there. Apologies for
cross-posting, to those who receive this as a post and as a project
ticket both. For reference, the ticket is here:
Re enhanced date support in CSL applications
The ultimate motivation for getting better date support right right in
the processor is practical: the prospect of more satisfactory live
application is the best trigger for getting to the actual coding.
Jakob’s proposals make sense to me personally, but to get them into
place will require coordination and contributions from several
quarters.
Formalization of the model: I’m not in a position to give the final
say on the formal dates model to be recognized by citeproc-js. I’m
happy to implement whatever is settled by the group, so long as it is
specific, and so long as the various permutations of input and output
under it are supported by examples. It would be a great help if a
formal model could be settled and generally agreed.
Input parsing: Jakob’s proposals raise challenges for the input side,
because they require finer granularity for seasons and circa markers
than CSL systems have had to cope with in the past. Despite the
occasional quandaries, parsed free text has served Zotero users pretty
well over past years. To cope with these proposals, existing parsers
(the current Zotero parser, or the prototype parser included in the
citeproc-js source) would need to be extended, in ways yet to be
determined. Either that, or some new method of date input would need
to be devised and implemented. That will be the watershed for
implementation work in citeproc-js; and to avoid any possible chilling
effect, I should say clearly that I won’t be able to put time in on
that myself. Parsing is just one part of the puzzle: there is also
data storage and retrieval to worry about in the application that does
the parsing. I’ll limit my own work to the citeproc-js side of the
API.
Output forms: If the granularity of input data is increased by
introducing per-date circa etc., the output forms of that data, and
the way that the various permutations will be controlled in CSL will
need to be settled. The need for clarity before coding in this
complex case has implications for workflow.
Most of the fixtures in the test suite to this point were written on
the fly, by me, in the course of coding the citeproc-js application.
For simple behavior, that works well enough, but for the complex nodes
(cs:names, cs:date) experience has shown that test design really needs
to be separated from coding. At two stages of citeproc-js development,
that effectively happened, with Rintze providing detailed guidance
over his name particle and localized date proposals. We’ll need a
similar workflow to see enhanced date formatting through to the end –
and it would be great, and save a great deal of time, if the process
could begin with completion of a set of formal tests to use as a basis
for the coding.
Hope this helps!
Frank