Revert new date object format

[cormacrelf]

Description

This reverts the JSON version of the EDTF date object that was introduced in #301. I read over that PR and the discussion. I don't think we need it at all, and it's better that it is deleted now.

If you want to completely remove the old format, we can also do that. I have drafted this PR to make that easy if necessary, without losing the one feature I think it has going for it ("issued": { "literal": "Han Dynasty" }). I have also removed the { "edtf": "..." } object format, because I don't believe that offered any utility, there are no circumstances under which you would want to have an edtf alongside any other property from that object.

Why?

I see the only options for the date object as either:

• preserve the old date object (date-parts & friends) in its entirety for compatibility, preserve it via oneOf EDTF / old
• OR, delete it and make CSL JSON v2.0 with only EDTF, since people are going to have to adjust code for the breaking change anyway.

I do not see the value in making a new date object whose only purpose is to replicate EDTF functionality in JSON. I get that it does what it says on the tin ("harmonises" the json/yaml input and EDTF) but in reality it is just a new, incompatible format that the PR itself recognised would have to be removed in favour of EDTF at some point. If it represents exactly the dates that EDTF represents, but does not carry any of the benefits of standardisation, e.g. being known to be in the well-defined ISO calendar, having literally any existing implementations, etc, then I do not see the point at all. If you want a data model for EDTF, simply read the EDTF specification. If you wanted a more computer-friendly format, or a more human friendly format (not sure?), the existing EDTF standard is better for both humans and computers.

What about harmonising with EDTF?

The thing that actually needed harmonising was CSL, not so much CSL-JSON. There are nevertheless some extensions to consider for CSL-JSON, but they do not include reproducing the functionality of EDTF. I have a number of suggestions based on my experience implementing the EDTF spec, I'll file separate issues for that. (Edit: citation-style-language/documentation#145)

(For history, ref #284 as well)

[bdarcus]

I see the only options for the date object as either:

preserve the old date object (date-parts & friends) in its entirety for compatibility, preserve it via oneOf EDTF / old

OR, delete it and make CSL JSON v2.0 with only EDTF, since people are going to have to adjust code for the breaking change anyway.

Your analysis makes sense to me.

So what is your preference vis-a-vis EDTF? I think I prefer the second option,.but I'm unclear on the first one.

Edit: looking at your EDTF branch, you mean allow this?

issued:
      edtf: '1300'

EDIT:

... though that doesn't match this PR; my understanding from the commits is edtf would now be encouraged?

issued: 2010-10-01?

Clearly EDTF should be our future; I think it's just a question of how we get there.

For sake of argument, if you otherwise are comfortable with what we've done for "1.1", including the title stuff (which is the other significant input model change; the "intext" feature is only relevant for styling), then maybe we go with option 1 but include a note that option 2 is the future (which is to say mark the old model for deprecation now, as in this PR, and then remove it in 2.0).

But given how hard and time-consuming it is to change CSL at all, it could be another decade before we see 2.0. Which gets to the bigger point about how we manage change going forward.

Maybe we need to figure out, and publish, a clear release roadmap for both input and style schemas?

@bwiernik @denismaier @andras-simonyi - see this and citation-style-language/documentation#145

BTW, while we're thinking about this, see also:

jgm/citeproc#93

Should the new "custom" extension property in the 1.1 input model be added to 1.0 as well? If yes, I'll create a new issue for that.

[bdarcus]

I edited the above reply a bit after looking at the commits, and am fine merging this myself, once the tiny typo is fixed.

The other questions, as you say, can be resolved separately?

Any other input here?

[bdarcus]

Merged. Thanks.

We can address any other related changes in separate PRs, if necessary.

[bdarcus]

Looking at this again, and citation-style-language/documentation#145, and wondering what we're actually doing about EDTF in the shorter-to-mid-run?

Seems EDTF validates, so are we recommending that going forward? Requiring it?

  "issued": "2020-10-01?"

Seems so; here's VSCode, offering completion and validation against the v1.1 schema, for YAML: