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  November 2018

DATETIME November 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, 29 Nov 2018 14:26:29 +1100

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (75 lines)

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?

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