Print

Print


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?