Thoughts on enhanced date support

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:

http://bitbucket.org/fbennett/citeproc-js/issue/115/support-seasons-and-uncertain-in-date#comment-289355

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

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:

http://bitbucket.org/fbennett/citeproc-js/issue/115/support-seasons-and-uncertain-in-date#comment-289355

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.

Agree on the need for formal models for all CSL data types, including dates.

As you’ll guess given my previous comments:

  1. I’m strongly resistant to formalizing a literal date type (e.g.
    date as only a dumb string, by definition completely opaque to
    machines). For the same reason, I’m uncomfortable with him defining
    “season” as “any literal.”

  2. I’d like to avoid inventing our own model, and simply borrow from
    other work (the iso/w3c date formats, edtf). So I get uncomfortable
    with Jakob’s comment in his proposal “(in contrast to for instance to
    ISO 8601!)”. If we diverge from widely implemented standards like
    that, we better have a damned good reason.

If people want to move forward on this, perhaps we need a wiki page on
the csl-schema site dedicated to this, with complete EBNF definitions
(including of “month”, “season” and so forth)?

As for …

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.

Yes, makes sense. This obviously does touch a number of issues outside
of CSL. So I guess it can’t reasonably move forward without some
coordination and agreement among implementors. And there’s a related
question of how we manage change in the schema and spec.

Bruce

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:

http://bitbucket.org/fbennett/citeproc-js/issue/115/support-seasons-and-uncertain-in-date#comment-289355

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.

Agree on the need for formal models for all CSL data types, including dates.

As you’ll guess given my previous comments:

  1. I’m strongly resistant to formalizing a literal date type (e.g.
    date as only a dumb string, by definition completely opaque to
    machines). For the same reason, I’m uncomfortable with him defining
    “season” as “any literal.”

We’ve had this discussion before. Zotero and citeproc-js are in
agreement that provision needs to be made, under appropriate
conditions, for exceptionally passing through a dumb string. But that
can be treated as an implementation detail, with which the formal
definition needn’t concern itself.

  1. I’d like to avoid inventing our own model, and simply borrow from
    other work (the iso/w3c date formats, edtf). So I get uncomfortable
    with Jakob’s comment in his proposal “(in contrast to for instance to
    ISO 8601!)”. If we diverge from widely implemented standards like
    that, we better have a damned good reason.

If people want to move forward on this, perhaps we need a wiki page on
the csl-schema site dedicated to this, with complete EBNF definitions
(including of “month”, “season” and so forth)?

As for …

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.

Yes, makes sense. This obviously does touch a number of issues outside
of CSL. So I guess it can’t reasonably move forward without some
coordination and agreement among implementors. And there’s a related
question of how we manage change in the schema and spec.

I’ll look forward to seeing what emerges.