"Revised EDTF"; On Mon, 22 Oct 2018 at 20:40, Denenberg, Ray <[log in to unmask]> wrote:
> The draft specification from 2012 has therefore been superseded and a
> revised EDTF Specification
> <http://www.loc.gov/standards/datetime/edtf.html> based on the revised
> 8601 is now available.
"future work"; Wed, 24 Oct 2018 Denenberg, Ray <[log in to unmask]> wrote:
> When I brought edtf to ISO - specifically, ISO Technical Committee
> 154, Working Group 5 – I joined the Working Group, to help move the
> process along. Things were going quite smoothly, until around March
> 2017, when the Convener (Chair), Mr. Klaus-Dieter Naujok, became
> seriously ill and resigned. ISO called upon me to replace him, and as
> it seemed apparent that the work would be terminated if I didn’
> (nobody else stepped forward), I accepted, and have been Convener of
> the group since. I have committed to remain until the new version of
> 8601 is published, and no longer. I do not plan to organize any future
> However, a new Convener has been chosen to replace me when I resign,
> Ronald Tse, who is with Ribose and works closely with CalConnect. I
> have invited Ron to join this listserv, and I'm sure he will be
> pleased to discuss any of your proposals.
"future work"; Thu, 25 Oct 2018 17:26:26 +0000, Ronald Tse <[log in to unmask]>
> .... I already see proposals for extensions of 8601-2 season codes,
> courtesy of Andy! If there is enough interest, it could potentially
> serve as the basis of a new international standard and registry. For
> example, a number of South Asian countries use a six seasons per year
> instead of the typical four.
> The field of date and time interoperability is not a closed case, and
> as you can imagine, the current projects are merely the tip of the
> iceberg. The completion of them will enable plenty of new work.
Hi Ray and Ronald,
Many thanks for your efforts on the ISO Working Group.
EDTF as published at http://www.loc.gov/standards/datetime/edtf.html is expressed in a beautifully terse form. Far easier to follow than its expression in (|ISO/DIS 8601-2:2016(e)|, https://www.iso.org/standard/70908.html, Annex C). Far easier to follow than its ancestral expression at http://www.loc.gov/standards/datetime/pre-submission.html ... getting rid of section 7 "Table of features" and Section 8 "BNF" seems like a good idea.
I have a number of questions.
I'll use the following references:
* |ISO/DIS 8601:2016(e)| ISO. 2016. *ISO/DIS 8601:2016(E)*. https://www.iso.org/standard/70907.html. 2016.
* |ISO/DIS 8601-1:2016(e)| ISO. 2016. "ISO/DIS 8601-1 - Data Elements and Interchange Formats -- Information Interchange -- Representation of Dates and Times -- Part 1: Basic Rules". In ISO/DIS 8601:2016(E). 1. https://www.iso.org/standard/70907.html. 2016.
* |ISO/DIS 8601-2:2016(e)| ISO. 2016. "ISO/DIS 8601-2 - Data Elements and Interchange Formats -- Information Interchange -- Representation of Dates and Times -- Part 2: Extensions". In ISO/DIS 8601:2016(E). 2. https://www.iso.org/standard/70908.html. 2016.
* |EDTF:LOC| Library of Congress. 2018. "Extended Date/Time Format (EDTF) Specification". http://www.loc.gov/standards/datetime/edtf.html. 2018-10-22. That is, the expression of (|ISO/DIS 8601-2:2016(e)|, Annex C) as found at the Library of Congress website.
* |ISO 8601:2019| ISO. Unpublished but expected to be published mid 2019. *ISO 8601:2019*. https://www.iso.org/standard/70907.html. Unpublished.
* |ISO 8601:20XX| ISO. Future work beyond |ISO 8601:2019|.
## Clarifying "Future work"
Looking at |ISO/DIS 8601-1:2016(e)| https://www.iso.org/standard/70907.html I see we are up to milestone "50.20 Proof sent to secretariat or FDIS ballot initiated: 8 Weeks: 2018-10-31". I'm not clear what this means but it sounds late stage. But then again an expected publishing date of mid 2019 is quite some way off.
So could you clarify what scope there is for any changes, particularly EDTF relevant changes, ahead of publishing |ISO 8601:2019|? Changes resulting from approved propositions arising either internally (from members of Working Group) or externally (e.g. from any of us on this LIST). Noting several possible change types (and partly to borrow from the language of |EDTF:LOC|):
* Functional (e.g. Whether the quarters division of a year should be supported).
* Syntactical (e.g Whether null, or some specific character, should be used for "unknown" in intervals).
* Presentational (e.g Given a rule's function and syntax is there a better wording or graphical layout to convey the rule; could the document be reorganised in such-and-such a way for clarity).
* Correcting obvious errors (E.g. Typos or other clear mistakes in the text).
Perhaps, at this late stage, you'd only be open for correcting obvious errors?
For |ISO 8601:20XX|, future work beyond |ISO 8601:2019|, are all of the above change types wide open (again my special interest is in EDTF relevant changes)?
Ray is |EDTF:LOC|, the webpage, something you've coded? Are you open to some suggested changes here?
## ISO and Openness
"future work"; Thu, 25 Oct 2018 17:26:26 +0000, Ronald Tse <[log in to unmask]>
> Allow me to take this opportunity to make a call for participation.
> There are few ways to participate at ISO/TC 154 work, either through
> nomination by your national standards body, through another liaison
> ISO committee, or an eligible liaison organization, such as CalConnect
> or OASIS (full list: https://www.iso.org/committee/53186.html).
> Either way, if you’re interested, let me know.
It was a very troubling thing, some months ago, that ISO requested links to the draft ISO standards at http://www.loc.gov/standards/datetime/pre-submission.html be removed (and so they were removed). That entailed that the latest, under development, EDTF spec was, in effect, stuck behind a paywall and with a great deal of uncertainty about the shape EDTF was taking. (Is there any story worth telling here?)
That became a catalyst for me to attempt to join the ISO working group, given my interest in helping to move EDTF along. Folk in my national standards body (Standards Australia) were very encouraging and welcoming in my making an application. I made an application but it is was regarded as insufficient as sent. Requests were made about the need for further justifications for why "the benefits [of] participating in TC 154 would bring to the Australian public" and "stakeholder support". I had addressed these in my application but, evidently, in a manner not deemed sufficient. But even at this stage Standards Australia was encouraging of any further attempt I might make to redo my application into the required form. I think it likely I could have worked with them to make the application adequate.
However, I declined to proceed because that application process crystallized for me that, ironically, this very process impedes stakeholder support.
I believe that any standard, by contrast to the way ISO is currently doing it, ought be open and provide liberty in that:
* Everyone be able to make suggestions for its improvement.
* Everyone be allowed to distribute the standard (with attribution).
* Everyone be allowed to copy the standard, make independent modifications to it, and distribute that modified version (with attribution).
* Everyone be allowed to use the standard for open or closed (proprietary) software.
* Everyone be able to access the development and release versions without cost.
... without going through an application process.
I remain silent for the moment on how decisions about the standard should be made.
So it is a great thing that you've:
* Made the Extended Date/Time Format (EDTF) Specification, at http://www.loc.gov/standards/datetime/edtf.html, once again open to the public without cost; and
* Have afforded some degree of public access to the ISO Working Group in virtue of your posting in this very forum.
For the longer term I suggest ISO, and our special interest is to do this at least for |ISO 8601:20XX|,:
* Adopt (something like) the openness principles above; and
* (In particular) move development of standards to Github or similar. That is, so any development version is publicly accessible; and to take advantage of the features of the issues forum - markdown, notification/subscription control, etc. Something like github would be vastly superior to, say, listserve.
This sort of thing, I'd suggest, entails that participation from any stakeholder is relatively frictionless. As an example I, some random person from the internet, found an error in the W3C HTML spec: I posted the issue to Github (having signed-up in 10 minutes some time ago); three days later it was corrected. Compare that with my experience (so far) of trying to make suggestions on |ISO/DIS 8601:2016(e)|: some lengthy formal application process, unsuccessful on the first go; with none of my suggestions ('til now) reaching those who might decide. Again, the requirement, among other things, to supply proof that an existing standard will benefit people (in one's nation) before being allowed to make suggestions on its improvement ... strikes me as absurd.
Ray and Ronald, of course your own powers to influence ISO may well be limited (and Ray I note your ISO participation ends soon). But, whether you can do anything about it or not, what are your thoughts here on opening ISO standards development (at least for |ISO 8601:20XX|)?