JohnLukeBentley
commented
6 years ago The following are my recommendations about:
- What to do about biblatex in relation to EdtfIso201x;
- EdtfIso201x in general; and
- Iso201x in general.
- IsoOrg: the International Organization for Standardization itself.
I don't necessarily feel strongly about all of my recommendations. That is, I'd be very much open to be persuaded differently. Especially since creative solutions might provide a way out of problems. So I provide the recommendations as something, at least, to push against.
Biblatex and EdtfIso201x
Levels
Recommendation:
Future biblatex support be directed at EdtfIso201x level 1 (and so also EdtfIso201x level 0).Biblatex formerly supported EdtfLoc level 1 and level 0 (with a few extras). Given the rough correspondence between the levels between EdtfLoc and EdtfIso201x, and that both specs seem only to support rare, or very rare, edge cases at level 2: probably coding time could be saved in the biblatex context by not bothering with EdtfIso201x level 2.
It is pleasing that the EdtfIso201x profile should attempt an exhaustive (and novel) handling of possibilities at level 2. If need to support the relevant rare edges cases arose, then EdtfIso201x looks well built to provide the relevant stipulation to implementers.
EdtfIso201x
Unknown and open ranges
Recommendation:
EdtfIso201x should use:
* For open: blank, as in "1982/" or "/1572".
* For unknown: Caret "^", as in "^/1970" or "1890/^".The designators used for unknown and open in EdtfLoc, the strings "unknown" and "open", have an obvious problem: they are English words. That's not a good thing for internationalization reasons. So it is right that EdtfIso201x should address this by having, instead, characters (counting blank as a character).
In EdtfIso201x the double dot ".." for open seems OK. Although it risks looking unintentional at the end of a sentence 2006/... Given, that is, that the end of a sentence might be marked by ellipses ... So for those reasons I think a double dot ".." should be rejected.
Blank for unknown seems like an odd choice conceptually. Biblatex historically uses blank not for unknown but for open. And that seems right conceptually. Blank simply seems better suited to indicate what open means: "some date that shouldn't be fixed".
So I recommend blank for open dates. In making this recommendation I give no weight to the convenience of preserving biblatex backward compatibility.
An argument against this recommendation, or the use of blank in any date context, is that blank might be confused for a value that has not yet been entered. That is, that the author of "/1572" has not yet asserted anything about the start date (neither that it is open nor unknown). If that argument has purchase then it speaks in favour have having explicit (non blank) characters for any kind of value (an explicit symbol for both open and unknown dates).
But assuming blank should be for open what, then, what should be the symbol for one of the dates in a range that is unknown?
It can't be "?" on its own, as in "2006/?", for "?" is already used to designate the that whole term is "uncertain". I take it that in this bibliographic context "uncertain" and "unknown" are conceptually distinct. "Uncertain", expressed as the question mark in "1587?", meaning "date whose source is considered dubious" (See "3 Terms and definitions", ISO DIS 8601-201x Part 2, p6). But an "unknown" date seems fitted to identify some date you wouldn't hazard a guess at, the "unknown" in "1783/unknown". So for those reasons the question mark "?" should be preserved for uncertain and not be used for unknown (whether alone or in combination with other characters).
What about, for unknown, the asterisk "*", as formerly supported by biblatex? For me the connotations of "*" come from SQL where it means: all possible values. That's a little bit jarring because the asterisk "*" in "2006/" doesn't mean "all years" but "all years greater than 2006". However, that's no large objection. One could come to understand that, in an EDTF context, the asterisk "\" takes on a slightly different meaning.
However I think I'd rather another character that didn't carry those connotations. Perhaps the caret "^": e.g. "^/1982"; "2006/^". I think that lends itself more readily to a stipulated connotation of being a pointer to a series dates either above or bellow the date that is specified. So, for the sake of presenting alternatives, that's my recommendation.
Century
Recommendation:
In EdtfIso201x remove support for two digit centuries. EdtfIso201x's provision of a two digit number to represent a century ...
For example ‘19’ may be used to indicate the time interval represented by ‘1900/1999’. ("C.4.4 Century", ISO DIS 8601-201x Part 2, p30).
... is superfluous if an implementation (like biblatex) supports EdtfIso201x to level 1. For at EdtfIso201x level 1 the unspecified "A year with one or two (rightmost) unspecified digits." is supported ("4.3 Unspecified", ISO DIS 8601-201x Part 2, p10). That is, "19XX" could be used to represent to "1900/1999".
Even more significantly, even if an implementation only supported EdtfIso201x to level 0, then a century can be represented by the EdtfIso201x level 0 supported time interval "1900/1999".
Any spec should be made simpler if it can. So I think removing support for centuries as two digits ought be done to make the spec simpler, given that centuries can be expressed at EdtfIso201x:
- Level 0 via time intervals (e.g. "1900/1999"); or
- Level 1 via unspecifieds (e.g. "19XX").
Reduced time precision
Recommendation:
Permit minute level precision at EdtfIso201x level 0
(Or, if it is to remain prohibited, make it explicit that it is so).Times with minute precision are common; and forcing such a time to go from "2017-10-28T04:47" to "2017-10-28T04:47:00" misrepresents the time.
It remains possible that the Edtfloc writers didn't intend to forbid reduced precision times. If their intention was to forbid they could have, and should have, written in the spec something like "omitting seconds in a time is forbidden". And so it remains possible that EdtfIso201x has simply inherited this oversight.
Iso201x
Move EDTF to its own part 3?
Recommendation:
Yes, with regard to Iso201x move the EDTF profile to its own part 3.As mentioned in the post above: this would make referring to sections in part 2 that aren't part of EDTF, conceptually easier.
Bookmarks
Recommendation:
Include bookmarks in the output.... for the love of easy navigation.
IsoOrg
Github
Recommendation:
That Iso201x, and all other draft ISO standards, be hosted on Github to take advantage
of the open issue tracker.The github issue tracker is a good one. And, moreover, provides an easy route to participation.
No cost
Recommendation:
That Iso201x, and all other ISO standards, be made available to the world without cost.It is an absurd state of affairs that any standard, being a thing the we want to be adopted as widely as possible, should have a barrier to adoption like cost.
Edit: "supports" to "supported"; added commas to fix grammar.
Edit: 2017-12-28 Grouped some recommendations under the "IsoOrg" term.
retorquere
plk
moewew
njbart
Crissov
inukshuk
danbri
Intro
Biblatex formerly (between v3.5 and v3.8, inclusive) supported an "Extended Date/Time Format (EDTF)" specification (to "level 1") located at http://www.loc.gov/standards/datetime/pre-submission.html. A new International Standards Organisation (ISO) draft specification has emerged that incorporates, with minor changes, that specification and "supersedes" it (thanks @moewew for flagging the change).
I've read the recent draft ISO and would like to clarify the differences between the old EDTF spec, former and current biblatex support, and the new draft ISO.
@plk indulge me addressing you in the third person even though you'll be the chief audience member in virtue of being the person who has implemented all this datetime stuff ...
@plk, with laudable enthusiasm, has gone ahead and started implementing the draft ISO for v3.9. @plk's partial implementation of the draft ISO spec has established that backwards compatibility is impossible (at least, and probably at most, with respect to open and unknown date ranges). And it seems that @plk has broken backwards compatibility in other ways on the basis that ....
I think that's reasonable. However, I'd would have suggested holding off for now, or at least, for now, having biblatex not break the old EDTF spec. Given that the new draft ISO warns "it is subject to change without notice" and that, indeed, it is we who might very well want to lobby ISO to make such changes.
Therefore, for biblatex, given the option between:
... I suppose we are going to roll with the latter, having started down that path. That need not be too onerous: the ISO revisions are probably going to be slow and few. And I also suppose that I'm happy that @plk has been prepared to break backwards compatibility in all sorts of ways. For that better allows us to evaluate the new draft ISO as a general matter freed, to a greater extent, from parochial worries about biblatex.
Anyway I suggest the purposes of this thread be:
And by "we" I mean to invite anyone who reads this post to participate. But I have in mind specific individuals who may find this of interest: @plk, @moewew, @retorquere, @njbart. ... but, as always, feel free not to engage this thread.
In this first post I largely confine myself to describing the issues. In the post to follow I'll make recommendations about those issues.
Semantics
To speak about this I'll use the following terms for the different standards/specifications:
As mentioned in a former version of biblatex.pdf ("2.3.8 Date and Time Specifications", p36) biblatex supported EdtfLoc levels 0 and 1. EdtfIso201x also uses the concept of levels but, naturally enough, what falls under those levels are (slightly) different with respect to EdtfLoc. A further subtle difference occurs between EdtfIso201x levels and Iso201x (the larger document) levels:
All this is largely to make the point that we need to be specific when referencing levels. For example EdtfLoc level 1, EdtfIso201x level 1, and Iso201x level 1 are (slightly) different.
Note also that generally, unless exceptions are mentioned, in all of those standards or profiles support for a higher level entails support for a lower level. E.g. To claim that an application, like biblatex, supports "EdtfLoc level 1" would be to say that it supports "EdtfLoc level 0 and level 1" (because this is what the specs oblige of an implementer). I have no objection, however, to anyone explicitly enumerating level support (i.e. speaking of support for "EdtfLoc level 0 and level 1" rather than "EdtfLoc level 1"). Indeed it is probably clearer to be explicit.
The differences
By and large EdtfIso201x (and the overall Iso201x) looks well thought through (as was EdtfLoc) and feature complete. But the overarching issue of interest is: What are the relevant differences between between EdtfLoc and EdtfIso201x?
Levels
The first difference is on the matter of levels. And the relevant issue is what EdtfIso201x level should biblatex, in the future, support?
Both EdtfLoc and EdtfIso201x categorize datetime formats into levels: 0, 1, 2. As mentioned above the levels in each spec are slightly different in terms of what they reference. However, there is a rough correspondence.
Biblatex formerly supported EdtfLoc level 1 (with a few extras). EdtfLoc level 2 seemed to target rare edge cases.
EdtfIso201x level 2 seems to target highly rare edge cases. For example,
So both EdtfLoc level 2 and EdtfIso201x level 2 seem to target rare, or highly rare, edge cases; although there's a slight variation in what those edge cases are.
Unknown and open ranges
EdtfLoc supports "unknown" and "open" ranges at EdtfLoc Level 1 as follows:
(See http://www.loc.gov/standards/datetime/pre-submission.html#extendedintervall1)
EdtfIso201x supports "unknown" and "open" ranges (at EdtfIso201x Level 0) as follows:
(See "4.4 Enhanced time interval", ISO DIS 8601-201x Part 2, p11).
Biblatex formerly supported "unknown" and "open" ranges as follows:
In summary ...
That's a problem. If biblatex is to transition to support EdtfIso201x (as currently specified) the meaning of blank, in the biblatex context, has to change from open to unknown.
Approximate and uncertain dates
EdtfIso201x preserves, from EdtfLoc, the representation of approximate (e.g. "1985-04-12~") and uncertain (e.g. "1985-04-12?") dates.
However, the representation of dates that are both approximate and uncertain has changed:
Century
EdtfIso201x supports a mere two digits as representing a century ...
EdtfLoc doesn't support this. But under EdtfLoc a century could be represented: with the unspecified range as in "19uu"; in addition to an explicit range like "1900/1999".
Other issues
There are other issues that arise that are not due to differences between Edtfloc and EdtfIso201x. Rather, they arise because of absolute reasons about the current form of EdtfIso201x.
Reduced time precision
When a time is present, shouldn't EdtfIso201x support minute level precision?
Edtfloc doesn't appear to support precisions less granular than a second, when a time is present at all. That is, something like "09:30:01" appears to be permitted but minute level precision, "09:30", appears to be forbidden.
Edtfloc stipulates:
So, as written, a reduce precision datetime, like "2017-10-28T04:47" appears to be forbidden under Edtfloc.
Biblatex currently (and formerly) reflects this with a message like:
... although biblatex permits output where the seconds are dispensed with.
EdtfIso201x essentially repeats the specification on this issue (See "C.4.2 Date and Time", ISO DIS 8601-201x Part 2, p29). That is, EdtfIso201x also appears to forbid minute level precision, where a time is expressed.
Move EDTF to its own Part 3?
Should the EDTF section of EdtfIso201x be an annex in part 2, or be moved to its own part 3?
Take the (currently existing) sentence like ...
("Annex C (informative) The Extended Date/Time Format - A Profile of ISO 8601 (Parts 1 and 2)", ISO DIS 8601-201x Part 2, p28)
... I think that (quoted) sentence would be a easier to follow if the EDTF profile were in its own part 3.
Participating in the ISO forum?
Participating in an ISO forum seems rather labyrinth. However, the relevant clues seem to be ...
From How we develop standards there is ...
https://www.iso.org/get-involved.html
From ISO/DIS 8601-1 the relevant technical committee is: ISO/TC 154 Processes, data elements and documents in commerce, industry and administration
... perhaps some of you are already participating and have a shortcut route to join?
In any case this very thread might serve as a calling card for those of us that want to join the ISO process.
The ISO 8601 landing page
Just to have it to hand:
Edit: 2017-12-28 Added "IsoOrg" term.