Print

Print


Hi John

(I blame Apple Mail for not creating proper indents for listserv…)

Most of the issues you mentioned relate to ISO/DIS 8601-{1,2}. The new FDIS documents (ISO/FDIS 8601-{1,2}) don’t have these issues — Ray has updated LOC’s EDTF to reflect all changes. LOC’s EDTF and the EDTF-sourced-syntax in ISO/FDIS 8601-2 are identical. That’s what I meant by no material changes.

As for the future of EDTF, it purely depends on LOC and Ray’s team (with the community) on how things progress. I believe most experts at ISO/TC 154/WG 5 would want to keep the EDTF contributions synchronized with EDTF itself, but it will hard to deprecate past practice since the ISO 8601 series is widely applied.

Ron

_____________________________________

Ronald Tse
Ribose Inc.

+=========================================================+
This message may contain confidential and/or privileged
information.  If you are not the addressee or authorized to
receive this for the addressee, you must not use, copy,
disclose or take any action based on this message or any
information herein.  If you have received this message in
error, please advise the sender immediately by reply e-mail
and delete this message.  Thank you for your cooperation.
+=========================================================+

On Nov 29, 2018, at 11:26 AM, John Bentley <[log in to unmask]<mailto:[log in to unmask]>> wrote:

Hi Ron,

Many thanks for the reply!

Apologies to all for the double post. This is my first time posting to this listserve and yahoo sent me a returned mail error message with respect to the first.

Given you've deferred to Ray on a number of points it might be right to let him respond to the matters below (no rush Ray).  But feel free to respond yourself, if you wish.

Incidentally your email technique of indenting replies doesn't work so well when we your view your message through the web <https://listserv.loc.gov/cgi-bin/wa?A2=ind1811&L=DATETIME&X=63CF5116759EC82DC8&P=2649>. I'd recommend old school quoting, using ">" for quotes (although modern email clients seemed to lack sufficient support for this).

## Clarifying "Future work"

So could you clarify what scope there is for any changes,
particularly EDTF relevant changes, ahead of publishing |ISO
8601:2019|?

This is obviously Ray’s area but from what I understand, the latest
EDTF fully includes everything that has been contributed to ISO/FDIS
8601-2:2018. Given if there are no material changes in the FDIS with
regards to syntax coming from EDTF (changes will be unlikely), the
published version ISO 8601-2:2019 will probably not affect EDTF.

To avoid some ambiguity, there is EDTF the single abstract standard. And it has concrete expression in two places:
* |ISO 8601-2:201X, Annex C|. That is, |ISO/DIS 8601-2:2016(e), Annex C|, as could be purchased (and can no longer be purchased?) at https://www.iso.org/standard/70908.html, or whatever behind the scenes revision, for publication (perhaps with further revision) as |ISO 8601-2:2019, Annex C|; and
* |EDTF:LOC| as at http://www.loc.gov/standards/datetime/edtf.html

As far as I can tell |ISO 8601-2:201X, Annex C| and |EDTF:LOC| are functionally (e.g. whether the quarters division of a year should be supported) and syntactically (e.g whether null, or some specific character, should be used for "unknown" in intervals) consistent. This is essentially stipulated at |EDTF:LOC| ....

the EDTF specification (this specification) is included as a profile of ISO 8601.

... with the caveat that it seems |EDTF:LOC| leaves out some detail available in |ISO 8601-2:201X, Annex C|. Presumably, in part to preserve the beautiful terseness of |EDTF:LOC|. For example |ISO 8601-2:201X, Annex C| stipulates that centuries may be represented by two digits (as with "19" for the twentieth century) while |EDTF:LOC| is silent on this.

I assume, at least for the moment, we want to keep |ISO 8601-2:201X, Annex C| and |EDTF:LOC| functionally and syntactically consistent. Also I assume, at least for the moment, |EDTF:LOC| is subsidiary to |ISO 8601-2:201X, Annex C|. That is, work has been done (or will be done) on |ISO 8601-2:201X, Annex C| and any knock on effect will flow through to |EDTF:LOC|.

Your "if there are no material changes ... (changes will be unlikely)" seems to miss the meaning of my question. My question goes to whether, as ISO WG members (and if the ISO process you are following allows it), you'd accept changes (especially functional and syntactic changes) to EDTF in |ISO 8601-2:201X, Annex C|, and therefore any knock on change to |EDTF:LOC|, at this late stage. For example, 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" and have any conclusions manifest in |ISO 8601-2:201X, Annex C|? In other words changes will be as likely or unlikely to the degree you are accepting changes. Are you accepting changes (especially functional and syntactic changes)?

Currently there is no ISO 8601:20XX, as the current version of ISO
8601:2019 hasn’t yet been published. ISO standards are generally
reviewed every 5 years. If there is a strong case for an in-between
revision, you could raise it to the ISO WG?

If you are not open for functional and syntactic revisions to |ISO 8601-2:201X, Annex C| to make it for publication as |ISO 8601-2:2019, Annex C| then I'm asking about whether "you" (it may be ambiguous to whom "you" refers ... many of the ISO WG members might disband soon after |ISO 8601-2:2019| publication??) would be open to functional and syntactic revisions for the next ISO version (whether in 5 years time, or some in-between revision)?

## ISO and Openness/Liberty

The WG (and Ray and I) has tried very hard to convince ISO to publish
ISO 8601-1 and ISO 8601-2 openly. It didn’t work out. As a second-best
alternative, the contributing documents to ISO 8601-2, including EDTF
and the CalConnect documents, are open standards and provide most of
the content available from ISO 8601-2. ISO 8601-1 however is only
available as an ISO paywalled standard.

... I would certainly wish ISO 8601 to be provided free of charge and have an open development process (alas, we proposed to make it free), but it is not our call at ISO.

I'm heartened to read that both your good self and Ray broadly support openness/liberty in Standards and have made (what would have been) a valiant attempt to shift ISO in that direction for |ISO 8601:2019|. A shame ISO didn't move. My guess is that there are historical and financial forces acting as a counter force.

... everyone can comment on EDTF, access the document online, is free
to use the standard. However, allowing copying and distributing
modified copies can run counter to the intention of standardization,
as they could promote fragmentation.

Yes we'd very much want to avoid Standards fragmentation if possible.

However, if "everyone can comment on EDTF" means that we can comment on this Listserve (or some other publicly open forum) and have that comment feed community conclusions that develop EDTF as expressed at |EDTF:LOC| then, necessarily, this will entail a divergence from EDTF as expressed in |ISO 8601-2:201X, Annex C|.

So, where is future development of EDTF to be led from? There seem to be two possibilities:
* Through (a partially closed) ISO WG developing |ISO 8601-2:20XX, Annex C|, whether this is the version published in 2019 and/or the subsequent ISO version; or
* Through an open community developing |EDTF:LOC|.

If it turned out that in virtue of ISO's closed nature further development of EDTF ought take place "Through an open community developing |EDTF:LOC|" then some degree of fragmentation might be the bullet to bite.

## TL;DR:

In short: How will, or how ought, further development of EDTF take place?