LISTSERV mailing list manager LISTSERV 16.0

Help for DATETIME Archives


DATETIME Archives

DATETIME Archives


DATETIME@LISTSERV.LOC.GOV


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

DATETIME Home

DATETIME Home

DATETIME  December 2018

DATETIME December 2018

Subject:

Re: future work

From:

John Bentley <[log in to unmask]>

Reply-To:

Discussion of the Developing Date/Time Standards <[log in to unmask]>

Date:

Thu, 6 Dec 2018 11:06:53 +1100

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (687 lines)

Ron,

 

I now see that the LOC Listserve message box does, in fact, support HTML.
Upon sign up I may well have changed the default message format from HTML to
plain text. So while we should continue to lament that many modern email
clients don’t promote, or even support, plain text quoting ... at least on
this Listserve I see that HTML emails are probably the easiest to work with
and quote. So that’s what I’ll do ...

 

Ray (and all),

 

## The current shape

 

It is informative for you to mention “major changes” from DIS to FDIS, with
respect to 8601 at large. Your own “backdoor” history onto the WG is also
interesting. 

 

EDTF in FDIS Annex A is much appreciated.. Comparing it to EDTF DIS Annex
C; and EDTF:LOC (indulge my including the “Of” in the acronym) <
http://www.loc.gov/standards/datetime/edtf.html> ; … I see the picture you
allude to. 

 

I see that this wonderful terseness at EDTF:LOC derives directly from
EDTF:FDIS. I see that EDTF:LOC essentially copies EDTF:FDIS text, with some
presentational explanations thrown in (that would otherwise be located in
the larger FDIS:8601) to enable EDTF:LOC to be read as a standalone. I see
that EDTF:FDIS, and therefore EDTF:LOC, has changed presentational styles.
From a sort of narrative form to a form with rule, optional (what I call)
metasyntax (e.g. “[year][-][month][-][day]”), and examples. I think that
presentational style much improved (as you’ll see I independently arrived at
a similar style).

 

I also see some welcome pruning of functionality. For example centuries as
two digits appears to be dropped from EDTF:FDIS (and that would explain its
absence at EDTF:LOC).

 

Incidentally can you verify that BNF metasyntax has been dropped from FDIS
8601?

 

Anyway, Ron, other WG members, and your good-self have evidently done a
great deal of hard work to push EDTF into what looks like the best shape
it’s ever been in. Thanks for that effort! And please convey that thanks to
the other WG members from me, random internet person.

 

 

## Future EDTF development

 

<quote>

As far as changes between the current draft and the published standard, it
is highly unlikely that there will be any functional or syntactic changes.
There could be minor presentational changes and of course, obvious errors
will be corrected (if caught). …

 

… … I do guarantee that the EDTF specification will always be available
from LC at no cost. …. that’s one way to influence the process: develop a
community standard that’s so popular that ISO will agree to keep it free.
EDTF isn’t quite there (yet) but as I noted it will always be available from
LC.   …

 

On your specific question ‘are you still open for WG members, or from
participants on this listserve, to debate "whether null, or some specific
character, should be used for 'unknown' in intervals’, unfortunately, no, it
is too late in the process, and I concede that the process is less than
optimal.   “… would be open to functional and syntactic revisions for the
next ISO version …”.   I envision that the next ISO version (beyond 2019)
would be the result of another community effort  leading to formalization in
ISO, similar to the effort that led to the current EDTF. (It might be LC
leading that effort, or it might not.)  So in that sense I suppose the
answer is yes.

</quote>

 

That very much answers my central question(s) about the future of EDTF
development, thanks! 

 

For the short term your answer is unambiguous. EDTF:FDIS is essentially
fixed, subject to minor changes. And so, at least for the short term, so
will EDTF:LOC be similarly restricted, excepting you are more open to some
suggestions here so long as they are consistent with EDTF:FDIS. 

 

For the long term your answer is also unambiguous. Interestingly that
answer points to a somewhat ambiguous situation. That is, it seems that EDTF
development for the long term is somewhat uncertain and there’s some degree
of openness about the possible directions it could take. 

 

 

## My historical relationship to EDTF

 

As a background matter …

 

… over the last two years or so I’ve been working with the devs of various
bibliographic open source tools (Chiefly Biblatex
https://github.com/plk/biblatex; and Zotero-Better-Bibtex
https://github.com/retorquere/zotero-better-bibtex;) to verify their
datetime handling works as desired. My role has been small … I just make
suggestions and run tests at my end after any responding coding effort by
the devs. I have also have some discussions with @ inukshuk, Sylvester Keil
having posted in this Listserve, the dev of edtf.js
https://github.com/inukshuk/edtf.js, the code library upon which
Zotero-Better-Bibtex relies. Early on in this process, the spearhead comes
in virtue of work with Biblatex, the EDTF standard (then in
“pre-submission/draft” form
http://www.loc.gov/standards/datetime/pre-submission.html ) became very
useful (initially suggested to us by Nick Bart, also a poster in this
Listserve, if I recall correctly). Naturally enough, given the standard is
born out of bibliographic datetime concerns; and given that even at that
pre-submission/draft stage the standard was in pretty good shape … skimming
through discussions in this Listserve archive I see that much of the hard
work had already been done (and of course EDTF leverages prior work
manifested in ISO8601:2004).

 

Most of the datetime work in Biblatex and Zotero-Better-Bibtex has been
done. There’s a few remaining edge cases. For the moment it is not
relevant/helpful to identify those edge cases (I’d also have to recall them
to mind and revisit the github threads).

 

Throughout this process EDTF, especially in the context of understanding it
against the subsequent formally embedding ISO/DIS 8601:2016(e), was …

 

On the pro side, among other things:

 

* Attractive because it largely stipulated one format for a circumstance
(E.g. you use “2001-02-03T09:30:01”; not that format or the space separated
“2001-02-03 09:30:01”). In this way EDTF not only “extends” ISO8601 but
“deletes” or “overrides” rules from it. 

* Was divided into Levels. Levels cleverly allow implementors to disregard
the rarer edge cases (e.g. by disregarding level 2); and, I imagine, provide
a safety valve during standards discussion … if one camps strongly favour
some feature/function and another camp thinks it is too rare a case to
bother with … that feature/function can be, as a compromise, be relegated to
level 2; and

* Of course, it provided bibliographically useful functionality (e.g.
“1756~” so that “ca. 1756” could be rendered).

 

On the con side, from higher stakes to lower:

 

* Was (arguably) missing one or two features/functions.

* Had (arguably) some problem causing syntax choices for which there exist
better alternatives.

* Ambiguous in a few places. Ambiguity that seems only to emerge when you
have your head in the detail of software implementation. Noting ambiguity is
a presentational matter.

 

When the ISO/DIS 8601:2016(e) pdf’s that were linked to from
http://www.loc.gov/standards/datetime/pre-submission.html disappeared at
ISO’s request then that seemed to signal that ISO had become a Standard’s
Borg Cube, assimilating previously open standards into their closed
processes. In effect locking up EDTF development. In retrospect I should
have visited this listserve (I was peripherally aware of the list for quite
a while) to disabuse myself of that faulty assumption (I could have just
seen, for example, your post of 2015-10-09
https://listserv.loc.gov/cgi-bin/wa?A2=DATETIME;794539ba.1510, which
references your participation in ISO WG discussions). However, I acted on
that faulty assumption and …

 

That became part of the catalyst for me to write a new standard that
attempted to track EDTF:DIS but have on top of that an additional, open,
format set. That is, I attempted to, among other things explore the
feasibility of: avoiding violating of any ISO copyright concerns; carry on
the spirit of the prior EDTF; and keep open the ability of present and
future software implementors to identify inadequacies of the format set and
suggest changes to the standard.

 

This exploratory, very draft, standard is publicly available at github. But
I won’t link to it presently partly because it would be too much information
to throw at you but mainly because I’m uncertain about its present value
given the assumption which served as a catalyst has turned out to be
significantly and thankfully false. Namely, the assumption that EDTF was
going to permanently disappear behind ISO’s closed process is false.

 

 

## EDTF:LOC future development

 

When thinking about this standard that I’ve written (substantially based on
ISO and EDTF work) I’ve yet to decide on the possible directions for it.
It’ll be one or more of:

 

* Kill it off. Something highly plausible given my having learnt that the
(defacto) chief EDTF author (if I’m right to identify you that way) was
both: a member of the relevant ISO Working Group (and the present chair no
less); in favour of open standards; has guaranteed EDTF will remain
available to no cost; and has preserved the ability of EDTF to be read as a
standalone document.

* Attempt to develop it as a separate format set that goes sits on top of,
but goes beyond, EDTF because it has features that EDTF doesn’t have (and
shouldn’t have). I’m disinclined to do this given a possible danger of
standards fragmentation; and EDTF already sits on top of ISO8601 … those
“sitting on top of layers” might become too convoluted. But I’ve been
experimenting with slightly different aims, that go to machine parsablity V
human readability, that might be worth developing.

* Use what I’ve written in comparison with the current state of EDTF:LOC to
see if we can salvage a few things for the improvement of EDTF:LOC.

 

Those matters, in turn, depend on a few things (perhaps even regardless of
the decisions to made above):

 

* How functionally complete, or almost complete, is EDTF:LOC? That is, how
likely is it that any present or future software implementer has, or will
have, a significant need for a bibliographic datetime function/feature that
is presently missing from EDTF:LOC? 

* How significant are any syntactic objections?

* Does EDTF:LOC have a significant number of ambiguities?

 

At the moment I’m unclear about the answers to those questions. I’ll need
to carve out some time to meditatively compare what I’ve written against the
current state of EDTF:LOC. Naturally it is also, perhaps chiefly, a matter
of discussion (and I note your “I would be happy to entertain suggestions
for improvement, as long as they are simple and don’t suggest technical
changes”).

 

As previously framed, thinking about possible EDTF:LOC development might be
divisible into two: the short; and longer term. Your “I would be happy to
entertain suggestions for improvement, as long as they are simple and don’t
suggest technical changes” might apply (at least) to the short term. That
is, to preserve EDTF:LOC’s functional and syntactic consistency with
ISO8601:FDIS (for eventual publication as ISO8601:2019) it is too late for
functional or syntactic suggestions. This short term EDTF:LOC could be
versioned as 1.0

 

## EDTF:LOC short term (“1.0”) suggestions

 

These suggestions probably, then, have to be confined to presentational
matters. 

 

I’m not sure how many presentational suggestions I could make. Perhaps the
best approach would be for me to finish my comparison between the standard I
wrote and the present state of EDTF:LOC and give you all those suggestions
at once. For to the extent that I have presentational suggestions they are
going to be mostly based on clearing up ambiguities in EDTF:LOC. However,
the clearing up of ambiguities has the danger of making the EDTF:LOC less
terse. And the terseness of EDTF:LOC is evidently a hard won state that is
worth preserving as far as possible.

 

However, to illustrate what I mean I’ll make a presentational and ambiguity
clearing-up suggestion right now about “Negative calendar year”

 

Presently you have at EDTF:LOC



<quote>

Negative calendar year

 

    Example 1       ‘-1985’

 

Note: ISO 8601 Part 1 does not support negative year.

</quote>

 

In the standard I have written I have a part that rewrites EDTF:DIS, and as
far as it references ISO8601:DIS at large, to (attempt to) clear up
ambiguity. My presentational style is to have the following rule components:
rule name; rule text; metasyntax; valid examples; invalid examples; (what I
call) a conformance type (here whether my rule “CONFORMS to”; or
“DISAMBIGUITES” the ISO8601:DIS standard); and justifying the conformance
type against references to ISO8601:DIS.

 

I have two rules that are relevant here. The first one is …

<quote>
Plus or minus year symbol rule. Negative years MUST be prefixed by the
minus sign (-). Positive years SHOULD NOT be prefixed by the plus sign (+),
but MAY be.
...
DISAMBIGUATES (|EDTF 8601 Profile - Annex C in ISO/DIS 8601-2:2016(e)|,
28–29, sec C.4.1 Date) at level 0. 
</quote>

I won’t give you the other components of the rule (metasyntax, valid
examples, justifying the conformance type against references to ISO8601:DIS)
for brevity and because EDTF:LOC just promotes positive years without a plus
sign. So it is probably without value to add this rule to EDTF:LOC. 

 

However, the second relevant rule (in full) is ...

<quote>
Astronomical calendar rule. The astronomical calendar is used. That is,
there is a year zero. Consequently, to convert a negative EDTF date into a
traditional BCE (or BC) format: decrement the EDTF date by 1 before taking
the absolute of the number and appending "BCE" (or "BC"). In other words,
around the year zero we have the following mappings.


EDTF

Traditional


0002

2 CE


0001

1 CE


0000

1 BCE


-0001

2 BCE


-0002

3 BCE

 

0125       // 125 CE. Not long after the year zero.
0001       //   1 CE.
0000       // The year zero, or 1 BCE.
-0001      //   2 BCE.

-0379      // 380 BCE.


Invalid:
  125      // Three digit year.
0125 CE    // Suffixes forbidden.
// "-0380" where the author intends "380 BCE".

CONFORMS with (|EDTF 8601 Profile - Annex C in ISO/DIS 8601-2:2016(e)|,
28–29, sec. C.4.1 Date) at Level 0.  

This specification assumes astronomical numbering, which includes the year
zero.

</quote>

 

I’d suggest it a good idea to prevent readers of EDTF:LOC thinking “-0380”
means “380 BCE” (or “380 BC”). 

 

And, of course, adding such a rule is just a restatement of a stipulation
in ISO8601:FDIS that the astronomical calendar is used (unless you inform me
this has changed in the update from DIS). So this isn’t a suggestion to
change functionality or syntax.  

 

If that suggestion has merit then you may want to update EDTF:FDIS (Annex
A) at the same time as EDTF:LOC (if the ISO process allows it). And to
preserve the beautiful terseness perhaps you’d only need to change your rule
to something like the following …

 

<quote>

Negative calendar year [Although I’d suggest, instead, “Astronomical
calendar” (preferred) or “Negative year”]

 

   The astronomical calendar is used. That is, there is a year zero.
Consequently, to convert a negative EDTF date into a traditional BCE (or BC)
format: decrement the EDTF date by 1 before taking the absolute of the
number and appending "BCE" (or "BC").

 

    Example 1        ‘0001’   the year 1 CE (or AD).

    Example 2        ‘0000’   the year 1 BCE (or BC)
    Example 3       ‘-0001`   the year 2 BCE (or BC).

    Example 4       ‘-0379’   the year 380 BCE (or BC).
    

Note: ISO 8601 Part 1 does not support negative year.

</quote>

 

Another, relatively trivial, presentational suggestion for EDTF:LOC (only)
goes to the date format of the document itself, currently “October 22,
2018”. The suggestion is to change this to a non-ironic format. I’m
imagining the ironic format is there either: as a simple oversight; or to
conform with Library of Congress website conventions (which would, in that
case, stipulate a US customary date format). If it is the later, what chance
have you of promoting EDTF by persuading the Library of Congress to adopt
the format for its website?

 

## EDTF:LOC long term (“2.0”) suggestions

 

If the position can be defended that - the current state of EDTF:LOC
entails that it is functionally complete (or almost so), there are no
significant syntactic objections, and the ambiguities are not too numerous
(or are numerous but could be cleaned up in the short term at EDTF:LOC) -
then perhaps there’s no long term EDTF development to be had. 

 

However, three prior suggestions by others seem to make that defence
difficult. From less consequential to more ….

 

* A syntactic suggestion by the Zotero-Better-Bibtex dev, that I’ll just
identify by his github handle @retorquere, that nulls for “unknowns” in
intervals is a bad idea. On the basis that machine parsing for absence of
something is trickier than machine parsing for the presence of something.
Better, so goes the suggestion, to use some kind of character.

* The functional suggestion by Nick Bart to permit seasons in intervals.
His initial defence of it at
https://listserv.loc.gov/cgi-bin/wa?A2=DATETIME;50cff1fd.1801 remains, for
me, compelling.

* The syntactic suggestion by Tony Benedetti to use a mnemonic scheme to
code most divisions within a year (apart from months and with some
arbitrariness for seasons). That is, as presented at
https://listserv.loc.gov/cgi-bin/wa?A2=DATETIME;abe4bb2c.1801 . This
proposal also seems compelling although I’m disinclined to allow northern V
southern seasons (as the current EDTF:LOC also allows). 

 

To the extent that discussions about the merits of these suggestions have
taken place on this listserve I haven’t yet seen a convincing counter
arguments against them (I haven’t yet read all the DATETIME listserve
archives but I have read all the recent discussion with regard to Nick’s and
Tony’s suggestions). No doubt further debate would have taken place in the
WG on those matters.

 

The relevant question here is: do any of those suggestions, all of them
taken together, continue to have sufficient merit such that a longer term
EDTF:LOC “2.0” development effort ought be regarded as begun? That is, so
that debate on these suggestions can continue. And apart from those
suggestions do we think it likely that there’ll be enough significant future
suggestions to merit “2.0” development? ….

 

Noting that two of these suggestions would break backward compatibility
with EDTF:LOC 1.0 and that you’d have therefore abandon your hope …

 

<quote>
I hope to see that at least the EDTF part of 8601 remains stable into the
distant future and that any changes or enhancements are backwards compatible
</quote>

 

But I think coming up with the right standard at its birth (e.g. in a 2.0
version given the 1.0 gate seems closed) will cause less pain than saddling
the centuries to come with a poorer standard. Better to break backwards
compatibility now rather than bind future generations with problems (think
of the problems Dionysius Exiguus causes us today by inventing, in 0525, a
calendar without a year zero: the Scoundrel!). For I do think EDTF will
become a ubiquitous standard and will even exceed the use and importance of
the larger 8601 standard that (now) contains it.

 

## Sign-off

 

Future EDTF development seems, for me at this moment, an uncertain and
nebulous pool of ideas swimming among creative impulses. But I hope there’s
enough specificity above to provide something for you to push against. 

 

Joy,

John Bentley

 

From: Discussion of the Developing Date/Time Standards
<[log in to unmask]> On Behalf Of Denenberg, Ray
Sent: Saturday, 1 December 2018 03:09
To: [log in to unmask]
Subject: Re: future work

 

Hi John –

 

Thanks for the comments about EDTF.  I’ll try to answer some of your
questions.

 

As far as changes between the current draft and the published standard, it
is highly unlikely that there will be any functional or syntactic changes.
There could be minor presentational changes and of course, obvious errors
will be corrected (if caught).

 

However, it is important to note that there were major changes from the DIS
to the FDIS (resulting from comments to the DIS).  There are limits to what
I am allowed to share at this point, however I am taking the liberty of
attaching the Annex which is the EDTF profile.  I think you’ll find that it
is dramatically improved. It is not quite as “pretty” as the LC version, but
that’s because of ISO format and style rules that we had to adhere to.  I
had no such constraints composing the LC version.

 

As far as future work, that’s out of my hands, and Ron is the one to
address that. Whatever happens, I hope to see that at least the EDTF part of
8601 remains stable into the distant future and that any changes or
enhancements are backwards compatible.

 

Yes, I wrote the LC EDTF page and I would be happy to entertain suggestions
for improvement, as long as they are simple and don’t suggest technical
changes. 

 

On the subject of openness, access, and participation … I do guarantee that
the EDTF specification will always be available from LC at no cost.  In
general though,  I no longer have any influence on how ISO operates.  I
leave that in Ron’s hands.  Your story about Australia’s attempt to
participate is somewhat familiar to me. The US also is not a member body of
TC 154 (for some political reason I don’t understand).  My participation in
this endeavor came about backdoor – through ISO TC 46 – my participation
began as liaison from TC 46 to TC 154 and it was a difficult administrative
process because there was no relationship between the US to TC 154.  But it
was TC 46, not TC 154,  that initially had interest in EDTF (long story).  I
was quite active in TC 46, many years ago, but most of my standards
development activity has been either National or ad hoc, for example EDTF,
which began as a community effort led by LC.  Another such effort (25+ years
ago) was Z39.50 which was a combination national (ANSI) and international
(community) effort, also spearheaded by LC.  I bring Z39.50 up for this
reason:  Originally an ANSI standard, it became so popular, worldwide, that
ISO wanted to make it an international (i.e. ISO) standard, and our position
was, yes, we can do that, but we insisted that it remain free, and ISO
agreed.  It was published by TC 46 (I  think, 1998, around 20 years ago) as
ISO 23950 .  So, that’s one way to influence the process: develop a
community standard that’s so popular that ISO will agree to keep it free.
EDTF isn’t quite there (yet) but as I noted it will always be available from
LC.  On “openness” in general, I leave that to Ron to pursue. 

 

On your specific question ‘are you still open for WG members, or from
participants on this listserve, to debate "whether null, or some specific
character, should be used for 'unknown' in intervals’, unfortunately, no, it
is too late in the process, and I concede that the process is less than
optimal.   “… would be open to functional and syntactic revisions for the
next ISO version …”.   I envision that the next ISO version (beyond 2019)
would be the result of another community effort  leading to formalization in
ISO, similar to the effort that led to the current EDTF. (It might be LC
leading that effort, or it might not.)  So in that sense I suppose the
answer is yes.

 

I hope this helps clear up some of these questions, and thanks for your
interest.

 

Ray

 

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

February 2019
December 2018
November 2018
October 2018
January 2018
August 2017
July 2017
June 2017
April 2017
March 2017
February 2017
August 2016
July 2016
May 2016
April 2016
March 2016
February 2016
January 2016
December 2015
November 2015
October 2015
August 2015
July 2015
June 2015
May 2015
April 2015
March 2015
December 2014
November 2014
March 2014
September 2013
May 2013
February 2013
October 2012
September 2012
August 2012
May 2012
March 2012
December 2011
November 2011
September 2011
August 2011
July 2011
June 2011
May 2011
April 2011
March 2011
February 2011
January 2011
December 2010
November 2010
October 2010
September 2010
August 2010
July 2010
June 2010
February 2010
January 2010
December 2009
November 2009

ATOM RSS1 RSS2



LISTSERV.LOC.GOV

CataList Email List Search Powered by the LISTSERV Email List Manager