Should we create an Open Datetime Format? #1
Comments
A justification for "Go:let's-create-it"The open-datetime-standard-bootstrap repositoryThis repository, open-datetime-standard-bootstrap, exists for two purposes:
So there'll be two "go" gates to pass through:
This repository, open-datetime-standard-bootstrap, will hold no code. Just before starting to write, if we reach that point, we'll create a separate, fresh, repository. Then open-datetime-standard-bootstrap will cease to be active. The germ of this proposal started in plk/biblatex/Datetimes. The draft ISO 8601-201x and EDTF. #65. There's no need to read it. But I'll quote from that thread and address some concerns raised there. Please endure me referring to some of you in the third person ... Against creating another datetime standardAgainst the proposal is: Firstly, it's generally bad to create multiple standards. @inukshuk mentioned the concern "I'm not too keen on standards proliferation". @moewew rightfully pointed ot the obligatory XKCD: "Standards" where Munroe captures the problem. The whole point of a standard (in an subject area) is so that everyone (in that subject area) follows that one standard. In a world with multiple competing standards (for the one subject area) you might recognize their failings and be inspired to create a better standard. But that can just result in another inadequate standard that, at its inadequate best, is adopted only by a few or, at its inadequate worst, makes following any of the competing standards less likely (because folk now have an additional confusion over which standard to pick). Secondly, ISO is THE world standards body ... whose standards are much more likely to be adopted in the face of whatever any other small group does. As @moewew put it
Thirdly, ISO 8601:201x, being nearly complete, has done most of the hard work. A few issues aside it is in a fairly robust state. We might do a lot of work only for a very small number of differences. RetortsOn the first objection, I'd agree that one should be reluctant to create another standard. Nevertheless if an existing standard (or standards) have a serious flaw then that might provide one with an overriding reason to create a new standard. That overriding reason exists: the ISO standard is closed. I'll expand on this in the next section. On the second objection, I don't agree that it is certain (as @moewew seemed to imply) that our standard will only ever exist as a little used standard. I think, rather, that is merely likely. But let's assume that it will only ever exist as a standard supported by a few bibliographic tools. Firstly, it doesn't follow that those tools have to choose between supporting our standard and ISO's. Rather, a bibliographic tool implementer can support both by supporting the union between the two standards. I'll go over this again later. Secondly, I'd suggest it is sufficient that our standard be supported by a few bibliographic tools. That's enough for success. We'd free ourselves from obstacles about what a closed and inflexible standard says must be done. If we, in the small community, have good reason to change the standard, as we come up against it in the process of playing with an implementation, then that standard is in our hands. On the third objection a key question will be: will having those differences be worth the effort? Indeed my current intentions, and this seems to be so far shared, is that the Open Datetime Format is intended to contain as small a number of differences to EDTF:ISO as we can. That might well mean that it not worth the effort (this is yet to be determined). However keeping the differences small is also a feature: it will mean implementers supporting the union between the two standards don't have much work to do (than they otherwise would trying to support disparate standards). For creating another datetime standardThere are two most important reasons for creating our own standard. Firstly, standards in the hands of ISO are closed. Closed in that:
No standard should be closed in those senses. All standards should be open. One of the reasons is that a closed standard is less likely to be adopted. Ideally THE world's standards body, the "International Standards Organisation", would become open. That would probably make creating an alternative standard unnecessary. Secondly, ISO standards development process is slow and inflexible. This is partly related to its closed nature (big or small suggestions from folk can't be made without having to jump through a time consuming and uncertain application process) but also the period of updating: every 5 years. That means it will largely remain impervious to aspects of datetime formatting that might be (and have been) discovered by implementers and testers of software systems. Having an open standard, by contrast, means that there can be a fast response to immediate (and worthy) discoveries of aspects of a standard that ought be changed. Of course a rapidly changing standard becomes difficult to follow. One would hope that a standard stabilises over time so that the need for change becomes rare. But, with respect to a datetime format, evidently we aren't there yet. For example, @retorquere and @njbart, in implementing and playing with Zotero-Better-Biblatex, in turn relying on EDTF.js, discovered that EDTF.js does not accept seasons in ranges (inukshuk /edtf.js / season range not recognized #12). @inukshuk, the implementer of EDTF.js, had a plausible interpretation of the EDTF:ISO standard: that it did not permit seasons in ranges. On further discussion there was remaining room for defending that interpretation but it became apparent, in my eyes at least, that having to defend that interpretation points to an ambiguity in the standard. The result seems to be that that the standard ought be changed to either: accept seasons in ranges; or be clear that it doesn't. But given that the (closed) ISO 8601:201x standard looks near to publication it's unlikely that issue will be resolved until 2023 (unless it has already been resolved by coincidence). By contrast an open standards process can make point releases as needed, without any real deadline. Even the W3C's HTML standard counts as a "Living Standard" in that sense. So our Open Datetime Format can be respond rapidly to discoveries about how the standard should be improved. That is not to imply that all and any suggestions would be folded into the standard. It's important that an otherwise "open" standard remain "closed" in one sense: it does not admit bad ideas, nor any and all ideas. A standard laden with bad ideas, or any and all ideas, turns into a standard not worth following. With the following example I take it @mowew meant to express that there should be some limits ...
... and I'd agree. And, at the moment, I don't have in mind that our standard would allow alphabetic zone abbreviations. That does seem to stray too far away from the aims of EDTF:LOC, and from the aims of ISO 8601:2004 or ISO 8601:201x for that matter. Note that EDTF:LOC, EDTF:ISO and the larger ISO 8601:201x use "levels". When thinking about potential disagreements about scope, levels are helpful device to provide room for compromise (as opposed to necessitating a schism). For example if you and I disagree about the importance of a format you might suggest we permit it at level 2, rather than reject it outright. That way it's a format the implementations that only care about levels 0 and 1 can ignore, but it exists in the standard as something for software that cares about the rarer cases (that is, software that wants to implement levels 0, 1 and 2). The benefits of Open Datetime Format in virtue of containing an ISO 8601 profileIn plk/biblatex/Datetimes. The draft ISO 8601-201x and EDTF. #656 I initially suggested, in broad terms, our creating an "independent standard". But @njbart provided a key enabling insight (in plk/biblatex/Datetimes. The draft ISO 8601-201x and EDTF. #656, 2018-01-26T19:22:44Z):
I'd also emphasize: It is not intended that 8601 profiles be approved by any formal body. So a (conforming) ISO 8601 profile can CLARIFY or DELETE features from 8601:201x. But if you EXTENDED or CONTRADICTED ISO 8601:201x that would make your profile not an ISO 8601 profile. Building off @njbart's idea I think the Open Datetime Format should, after all, be an independent standard and not an ISO 8601 profile. Rather Open Datetime Format should be our own independent standard that contains an ISO 8601 profile (of our own). That ISO 8601 profile (of our own) will just CLARIFY or DELETE features from the EDTF:ISO. Then, in addition, we EXTEND and CONTRADICT EDTF:ISO where necessary. I think this better uses @njbart's insight about ISO 8601 profiles while preserving where he wanted to go "we should of course reserve our right to amend [our standard]". Composing the Open Datetime Format that way gives us two benefits: Firstly, the part which is an ISO 8601 profile enables us to track and leverage the work that ISO has done, and will do, on EDTF. That can save us a great deal of work. Work is saved both in terms of: designing/writing the standard; and for implementers of standard consuming software (e.g. Biblatex, EDTF.js, Zotero-Better-Bibtex, etc.). Implementers of standard consuming software may choose to support both EDTF:ISO; and Open Datetime Format. That is, to guard against the likely outcome of Open Datetime Format not being widely known (let alone adopted). Implementers providing such support would, therefore, be supporting the union of both standards. That is, permitting things in one standard not permitted by the other. But because Open Datetime Format is to be tracking the Annex C profile in ISO 8601:201x, the differences between the two is going to be small and therefore the implementation effort should be small (relative to trying support the union between disparate standards). Secondly, that should enable us to avoid copyright infringement. As quoted above ISO explicitly endorses that people create profiles without explicit approval (in other words ISO has given blanket tacit approval for profiles). So we can create our ISO 8601 profile without explicit approval. Anything we create in addition, any EXTENSION or CONTRADICTION of EDTF:ISO would be, by definition (I would think), a creation of our own (perhaps with fair use references to EDTF:ISO precisely to note how it is different from the original). Of special note, with relevance to the copyright issue, is that ISO itself has incorporated the open EDTF:LOC ... and we'd be mostly, therefore, be indirectly referencing the substantial open work done by the EDTF folks at LOC. Although it is true that EDTF:LOC was based on ISO8601:2004 (and this is explicitly mentioned at http://www.loc.gov/standards/datetime/). The end of the beginning?I'd be happy to clarify anything from above. I suggest that, for the moment, we stick to this one thread for the single purpose of deciding the first go/no-go gate. That is, for reaching a point of "it so far seems feasibly good, let's create it" or "it so far seems feasibly not good, let's not create it". By all means raise and express (thread related) issues (in this thread), disagreements, etc. before revealing your individual "Go:let's-create-it"/"no-go: let's not create it". My individual "Go:let's-create-it" depends on the "Go:let's-create-it" from the bibliographic tool implementers:
... and ...
If we can create a good standard and implement it robustly in edtf.js, zotero-better-bibtex, and biblatex ... that would be a good start towards demonstrating its worth to others: we'd have developed and tested the standard against software implementations. Given that Zotero currently permits anything (?) in the date field it is unnecessary to get the Zotero devs on board. Although I intend to mention it to them in case it might be of interest. I've been intending to discuss with John MacFarlane, the Pandoc dev, the better support of datetimes in the Pandoc citation/references mechanism. So I'll mention to him this current effort (if we go ahead with it). I intend to invite the folks at EDFT:LOC over. Those folk will have a great deal of valuable experience. What say you girls (yet to come) and boys? Shall we paint our faces blue and charge down the grassy slope (to engage in creative battle against the datetime format ideal, for FREEDOM)? |
|
Reserved for updating discussion conclusions. |
|
I wouldn't weight any go-nogo on my insights. The exposition above outlines three kinds of concerns concerning to the new standard, roughly:
Since my primary concern is 3., I have a strongly skewed bias. I mean to parse anything that is recognizable as a date, and that includes a lot of things that aren't even close to the proposed standard, and some things that probable contradict standard (the parsing of and then I'd probably implement the non-conformant output, as my users just need to get work done, and biblatex (for good reasons) moves slower than I do. It's just easier for me to bend. On the topic of open vs free, I will admit that I use the terms interchangeably in casual conversation, but I'm on board with the distinction Stallman makes; "open" describes mostly properties of the product (that its source is not closed), free describes an attitude towards user interests. I think open is used more often than free mainly because it seems to me that contrary to what Stallman thinks, people seem to associate free with gratis before they associate it with liberty, which sends the exact wrong message, contrary to open, which probably sends the message Stallman wanted to convey, even if it actually doesn't principally defend the same things. WRT to the standard being described above, I think it's more important to pick a license that defends the things we care about than debates about free vs open. |
|
Thanks @retorquere. I'll firstly represent your current situation (before any implementation of an Open Datetime Format) back to you, off the back of your description (and my use of your tool). Correct me if I misunderstanding anything. At your input end you have Zotero (and only Zotero). Zotero permits anything in its date field (including literal strings like "My Birthday"). Zotero users will therefore input the widest possible variety of date format (e.g. "My Birthday", 23rd Feb 1978, 2/23/78, 23-Feb-1978, etc). They aren't going to necessarily conform to an Open Datetime Format. They aren't going to necessarily conform to ISO 8601:2004. So you need to parse those wildly varying datetime formats in preparation for disparate output formats (e.g As output by Better CSL JSON, as output by Better Biblatex, etc). CSL JSON, for example, has it's own datetime format that doesn't conform to any ISO 8601. E.g. I observe In the case of Better Biblatex you are bound to output what Biblatex wants. You then imagine the scenario where Biblatex claims to support Open Datetime Format ...
... you'd ...
If that's all correct then that makes sense. In the case of a biblatex-as-implemented/standard mismatch you'd be wanting to privilege biblatex-as-implemented until you get notice of the mismatch being resolved. I don't think that presents a particular problem for the standard (and I'm not suggesting you think it does). Rather, it would just mark a lag between the standard and the implementations.
Perhaps I could ask a less demanding question (there's no sarcasm there). Would it be right that if both @plk and @inukshuk were attempting to support ODF (possibly in addition to supporting EDTF:ISO) then that would present no particular problem for you? In that case and to that extent, in other words, you'd be on-board with ODF. Relatedly @inukshuk (with continued thanks) has already indicated he will support this (allowing he'll need to review the current thread). However if he didn't support ODF (e.g. imagine a bus hit him tomorrow) then that would create a great deal of work for you that wouldn't otherwise exist. That is, because EDTF.js currently does some heavy lifting for you. Is that right? |
|
@retorquere, another issue is: If biblatex said it supported the union of ODF and EDTF:ISO, and the biblatex implementation did so perfectly, then you might have a quandary where those standards contradicted each other. Assume, for uncertain and approximate: ODF uses
Would you be able to (without extra pain) output to biblatex the user's respective date formats, or would it be necessary (to avoid pain) to choose one format or the other? If the answer is the latter, then if Biblatex were supporting the union of both standards, perhaps it would nevertheless be helpful for Biblatex to indicate a preferred standard. |
Absolutely. I prefer coding towards standards, and not because I think @plk and @inukshuk present shifting targets, but that I'd have a canned answer to users who ask "why do you dot this instead of [insert workaround for a reference they're working with rendering different from what they want]". It's just easier for me to say "the biblatex manual says" or "the EDTF standard says" (if that canned answer means their problem is fixed, natch) than to add a new behavior to BBT for every edge case presented (of which there is an endless stream) ... and then I usually do something to get the user going, because at the end of the day, BBT is not an standard-enforcement tool but a way to efficiently get your references in your documents. This is BTW the major reason for my postscript facility; for stuff that is really a solitary edge-case, I can now say "easy, drop in this postscript" and be done with it.
EDTF absolutely does some heavy lifting for me. The heuristic detectors are very simple and only detect blatantly obvious textual dates or misarranged fields matching very strict patterns. The actual date parsing for most stuff gets done by EDTF. EDTF.js going away would present a major problem for me.
I'd choose the one that biblatex supports; my preferences ( bibtex is a whole other matter. Nothing is really documented, or standardized, and I keep hoping it will just roll up and die already. There's one problem I forgot BTW. EDTF.js doesn't parse (what I recall to be) older versions of EDTF, so given a date var I'd very much prefer not to have to do that. |
Great! Then that seems to be enough of an assent from you for us to move forward on ODF, other players (@plk and @inukshuk chiefly) and factors (any counter arguments from others) pending.
Could you clarify that? I mean what would you do?:
All that, of course, assumes an implementation best deals with a new and little used ODF standard by supporting it in union with EDTF:ISO. Perhaps it would be better, instead, to bite the bullet and only support ODF. At this point of the process (and night) I can't decide. On Open V Free.
In this context that may well be right. Start with the list of principles we care about, see what license best matches those principles, and the camp that puts us in probably shakes out of that. However, I wouldn't want to discourage anybody who, in thinking about ODF, wants to grab that stick from the other end. E.g. By defending a Stallman-like stance that starts with the political/moral principles of freedom.
Yes that's both consistent with my understanding and helps solidify my understanding. It seems to reflect, for example, ...
But the distinction between "free" and "open" does seem ... tricky ... as Stallman acknowledges
Incidentally ...
To defend Stallman on this point, he is very much aware of the ambiguity, ...
Edit: Inserted comment and quote about trickiness of "free" v "open". |
Yes, absolutely.
Pragmatically, I'd do whatever @plk or @njbart tell me to do. I know very little about csl and biblatex.
People who actually care deeply about these matters will always be divided on this. The open source crowd seem largely to be ok with free though.
This is correct, Stallman is aware of this, but then still seems to assume people will look beyond superficialities to find out what is actually meant. This is not my experience in these matters. So from this perspective of the debate, the term "free" is going to be most meaningful to people already persuaded one way or the other (because these are the people who took the effort to find out about the difference). It feels to me like it is unintentionally preaching to the choir in this way. My views are in line with Stallman btw. Open source has very little value to me if it isn't also free software. |
|
I hate to play the wet blanket, but I have to admit I’m not entirely convinced. My original proposal, more modest, if not minimalist in spirit, was to create and maintain nothing more than an ISO 8601 profile. The only extensions/deviations I had in mind are very narrowly circumscribed, and essentially correspond to the kind of exceptions listed on the edtf.js home page – I tend to think these are all small enough to permit using the name of and claiming overall conformance with ISO 8601. However, I wanted to be upfront at the same time about the fact that any of the profile’s conscious deviations from ISO 8601 should be considered to be features, not bugs. My feeling is that the attempt to introduce a new “open” standard – while certainly an understandable move considering the closed-committee approach chosen by ISO – ultimately will do little for, if not hinder, what I assume is what most of us involved in this discussion would like to see, i.e., the widespread adoption of a unified date standard. This purpose, I feel, would be served better by continuing to sail under the “ISO 8601” flag, and leveraging its prestige, while creating a profile of it that can be adapted in certain small details to suit the needs of the bibliographic and reference management software communities. Edit: typo |
|
@njbart ...
That is most welcome.
Yes that desire should be kept in the heart. But I do think that goal unlikely, whatever course we take. However, that a laudable goal is unlikely is not necessarily an impediment to taking action that risks achieving that goal (a thought that can't help bring Elon Musk to mind in his description of his motivations) . Moreover, as I mention, if there is adoption among a few bibliographic tools that would count, in my view, as a success in-and-of-itself: that would be motivating enough. In any case reaching that milestone would be the necessary small step on the way to widespread adoption. You ...
Me too ...
You..
I should clarify my earlier allusion to the "feature/bug" dichotomy, as it might have been misleading ...
I only meant that if it is proposed we go down a path entailing a great deal of work to implement a small number of differences then:
At that point of the argument I wasn't imagining an objector who'd, instead, argue for a large number of differences. (But I wouldn't want to close off someone arguing for a larger number of differences, because at this stage of the creative/feasibility game all ideas are on the table. However, my prejudice is that most of us so far involved are interested in keeping the differences small in number).
If my interpretation of the ISO rules about what counts as an ISO 8601 profile are correct then, formally and strictly, a feature in an ISO 8601 Profile can only CONFORM with, CLARIFY (including disambiguations), or DELETE features in EDTF:ISO (or the ISO 8601:201x at large). And if your standard has features that CONTRADICT or EXTEND the features found in EDTF:ISO (or the ISO 8601:201x at large) then, formally and strictly under ISO's rules, your standard doesn't count as an ISO 8601 profile. It seems that your current suggestion entails not being so strict and formal about those ISO 8601 rules. I'll attempt to flesh out the best way (I can think of) to make your suggestion plausible .... For some candidate differences between the standards the conformance category is going to be ambiguous. For example it's not clear whether seasons-in-ranges is an EXTENSION of EDTF:ISO or a CLARIFICATION. Given the ambiguity we could stipulate it as a CLARIFICATION. That would let seasons-in-ranges through the gate for inclusion into an ISO 8601 profile. So that'd be fine. However, some candidate differences are going to unambiguously fall into the EXTENSION or CONTRADICTION conformance category. For example both @inukshuk (perhaps off your input) and I have independently thought to CONTRADICT EDTF:ISO on the symbols for open and unknown date ranges. It seems your suggestion in cases where a candidate feature unambiguously falls into the EXTENSION or CONTRADICTION conformance category is to ignore the ISO rules on the basis that these EXTENSIONS or CONTRADICTIONS are going to be small in number (perhaps compared to the CLARIFICATIONS or DELETIONS we propose). That is, that our standard is not, strictly and formally, an ISO 8601 profile but it so close that we'll stipulate it as an ISO 8601 profile. If that fairly represents the position you had in mind then two objections come to mind. Firstly, if one is going into bat for standards in general then it doesn't bode well to start letting things through that unambiguously are non-conforming under the rules of the standard. Here we have a (meta-)standard about what standards count as an ISO 8601 Profile. Your suggestion seems to entail letting through a non-conforming standard via a route that seems to attack at the very fabric of conformance. Secondly, even if we convinced ourselves of this it wouldn't follow that ISO would be so accommodating. For example, at the point where we'd register our profile in the ISO database they might (reasonably) refuse. As well as not letting us register our profile ISO might press copyright concerns ... on that basis that implicit permission is given for ISO 8601 profiles, not "copies" of ISO's standard that masquerade as an ISO 8601profile. That would sink "continuing to sail unter [sic] the 'ISO 8601' flag, and leveraging its prestige". But there is an alternative to what I've proposed (an independent standard containing an ISO 8601 Profile plus extensions and contradictions) and what you've proposed (a standard that is stipulated as an ISO 8601 profile even though, in a few places, it is not strictly conforming). That alternative depends on examining the candidate differences so far on the table ... You had in mind differences that
So combining the issues/propositions/implementations find on the edtf.js home page with what I raised in Datetimes. The draft ISO 8601-201x and EDTF. #656 we have ...
As mentioned if a feature is ambiguously a CLARIFICATION or EXTENSION of EDTF:ISO then we could stipulate it as a CLARIFICATION and bring it through the ISO 8601 profile gate. On that basis the first four candidate differences can count as something that could be listed under a strictly conforming ISO 8601 profile. We could, then, abandon our desire to CONTRADICT ISO on symbols for unknown and open. That would give us a strictly conforming ISO 8601 profile. And our standard would just be that strictly conforming ISO 8601 profile. I'd suggest that's very much a viable third option. However, it would be bought at the cost of having to abandon the right to unambiguously CONTRADICT or EXTEND ISO. As an example of that cost Tony Benedetti has a very worthy suggestion with regard to divisions of a year DATETIME@LISTSERV.LOC.GOV > "Division of Year codes", Thu, 4 Jan 2018 20:01:04 -0500. Another example (contradicting Tony's suggestion) is to have quarters expressed using These suggestions seem to be evidence of the existence of further potential CONTRADICTIONS and EXTENSIONS lurking out there, waiting to be discovered. The third alternative would shut the door to those suggestions. Edit: Major rewrite due to keyboard accident resulting in premature posting. Edit: Added "And our standard would just be that strictly conforming ISO 8601 profile." Edit: Added "These suggestions seem to be evidence of the existence of further potential CONTRADICTIONS and EXTENSIONS lurking out there, waiting to be discovered.". |
I think I had in mind to enlist your help working through a conceptual problem rather than soliciting, so much, the particulars of your situation. That is, evaluating whether an end tool, like biblatex, could plausibly support the union of ODF and EDTF:ISO even though they contradict each other in places; and would that cause any in-principle problems for a tool like yours (that feeds biblatex). Working through that problem might result in the conclusion that biblatex ought: support a union without privileging either standard; support the union but declare a preference; or support only one standard (which might count for or against ODF). But I think that's a complex enough problem to ignore it for now. Your mentioning the particulars of your situation "Pragmatically, I'd do whatever @plk or @njbart tell me to do" helps clear the way for ODF to proceed (it removes one of many potential blockers) and allows you to not be involved in the development of ODF (you can just consume whatever conclusions we arrive at). Of course you'd be always welcome to be involved in the development of ODF, if it proceeds and you have an interest. Free V open
Or, perhaps, most people who are in the "free" camp care deeply about these matters while many in the "open" camp don't (and that is part of Stallman's complaint).
Yes it might be that most folk at large encountering "free" in the context of software aren't going to be exposed to the discussion about it's meaning. Incidentally I did suggest to the FSF the disambiguating phrase "freedom software" (which struck me as solving the problem at once). However, I was (helpfully) pointed to Stallman's response
That company seems to be http://freedomsoftware.co.nz/. I now have it on my list to ask them how they'd feel about the free software movement adopting "freedom" in the place of "free". It would be reasonable for them to object.
Your view might be partly consistent with Stallman's but, you'll know, his position is thicker: not just that open source software should also be free (at liberty) software; but that there should be no proprietary software. I certainly feel the spirit of Stallman through me with moral indignation at non-free standards. But I'm not sure that I can march that far with Stallman on software. Not least because I have, and intend to, made money off proprietary software. But, of course, that might just represent a conflict of interest that prevents me thinking clearly about Stallman's moral appeals. In any case, I admire him greatly for staking out his position. If he didn't exist we'd have to create him. I also assume Stallman wouldn't endorse what I've proposed for our standards:
|
|
I've been toying with the issue of the separator between dates and times. Under EDTF:LOC and EDTF:ISO "T" is the only separator, as in
There may well be reasons that immediately come to mind for rejecting all of those possibilities, and sticking with the EDTF:LOC/EDTF:ISO standard. However, this would be another example feature suggestion that couldn't be entertained under the third ODF-composition option (where ODF just is a strictly conforming ISO 8601 profile). That is, there'd be no use even opening the issue of date and time separators in order to hear the immediate reasons for rejecting a space proposition. |
|
(sorry for the extended discussion guys. It's sort of relevant to the ODF discussion, but I also just find it interesting)
I like conceptual problems, but this one is equal parts conceptual (yay!) and policy/political (err...), and if I have to evaluate the problem from the perspective of BBT (which is a pragmatic endeavor), I just don't have much to say that is going to be relevant to the discussion. It may sound like a cop-out, but I really don't know much about csl or biblatex or how it's used; I don't use CSL at all myself, and I'm a fairly unsophisticated biblatex user.
I'd have to. I can chime in occasionally when I do have opinions or experiences that may be relevant, but at the end of the day, @plk and @njbart know a vastly wider scope of issues that changes in biblatex would affect.
I see why it can seem that way, but I don't think you could look at the BSD folk and say they don't care about how their software impacts the world and how that is expressed in their licensing. The thoughtful open and thoughtful free people just have a different value system underpinning their work. In many cases free will be good enough to qualify as open, but not always.
I didn't know that. Still then "libre" sounds to me to be a term that both expresses the intended meaning better, while at the same time inviting those who don't already know what it means to find out.
Right, I do forget that sometimes. I don't have a coherent stance of this I'm afraid. I feel it's OK between consenting parties that one builds software that the other can't disclose, much like I think it's OK that I tell you something personal on the condition that you keep it secret. On the other hand, there's plenty software that's foisted upon me (the dreadful hours registration tool at work comes to mind) where it's an outrage that I can't fix it if I have to use the blasted thing. The problem is of course that this dreadful piece of software (there must be a tenth circle where the creators of DAX suffer) was negotiated between two consenting parties, being my employer and the hacks that threw together the POS. I have for the most of my working life earned my keep with proprietary software. I try to release open source where I can, but I'm obviously either not religious about it, or I'm a hypocrite. I haven't decided between the two yet. For standards, certainly public standards, my position is simpler: I think it's immoral to raise the expectation that people should follow these standards without at the very least making these standards available without restriction. I know people who do OSHA work where the law-of-the-land says "you must follow standard X, or make sure you adhere to [immensely complicated-to-prove guaranteed outcomes that you'll have to translate into practice]", where standard X costs big money. I think that should be outright illegal. Stakeholder involvement is harder I think. It's not so easy to me to see whose interests should weigh in what amount. It's certainly impractical to involve everyone who could potentially have an interest, and that's not even touching the future generations problem.
That sounds about right to me.
I would hope that if he would object, it would only because he'd object to proprietary/closed software under any circumstances including this one. I would certainly hope he'd not see software built from a standard as a derivative work from that standard. That would go much too far for me, and it would endanger free-software efforts to reverse-engineer their way out of closed-source tarpits (because the system being reverse-engineered could be seen as a standard of sorts to work from). |
|
@retorquere, along the lines that you suggest: these sort of broad free V open issues are related to ODF but probably best postponed for a dedicated separate thread, if it comes time for such a thread. ... and you and I have perhaps lured each other into this incidental, albeit generally important and interesting, discussion. In other words at this point in the thread the two interacting issues that @njbart and I are engaged in (that you and anyone else are welcome to, but not obliged to, weigh in on) ...
... are probably the next things to focus on. For those two interacting issues demand an ODF enabling solution; or resolution into the conclusion that ODF should not proceed. |
|
@JohnLukeBentley – To be clear, I’m worried almost exclusively about missing expressivity in ISO 8601 (the only issue I am currently aware of here are season-season intervals, though there might be others), and much less so about notational variants (
I’m not sure whether #5 is still an issue for edtf.js – ISO/DIS 8601-2:2016(e) (2016-10-26), section “4.4 Enhanced time interval“, now has “Unknown – Start or end date unknown. The start or end date may be left blank to indicate “unknown“.” and “Open Start or End – Double-dot ( Season-season intervals, however, may well fall under EXTENSION (that’s @inukshuk’s view, following information provided by Ray Denenberg on the EDTF mailing list, and though the latter reported later on that he’s “talking with ISO” with the aim of having season-season intervals included in the standard, we may very well end up with a standard according to which season-season intervals are invalid.)
As far as I can tell, there is no “ISO 8601 profile gate” per se. Registration is not mandatory, it is merely encouraged in order to avoid duplication of profile names. (ISO/DIS 8601-2:2016(e) (2016-10-26): “It is not intended that 8601 profiles be approved by any formal body; any person or community can develop a profile. There should however be a unique name for every profile so that it may be referenced.”)
Agreed, but what about formulating a strictly conforming ISO 8601 profile, combined with a set of “Additional recommendations” (or some similar designation)? These recommendations would include items like “Implementations of this profile are expected/encouraged/… to treat season-season intervals as valid.” I’d consider this a very viable fourth option. |
|
@njbart ... My worries about notation issuesYour expressivity V notation distinction is helpful. It would be true that there's a sense in which issues of expressivity are prior to, an therefore more vital than, issues of notation. For example if you felt the need to express a datetime that was both uncertain and approximate and a standard provided no way to do that then that's more of a problem than having to express your uncertain and approximate date using your less preferred notation. But I worry about the notational choices a standard makes for five reasons: human readability; human usability; parsibility; machine usability; and ad hoc reasons. For example:
The choices to be made about those issues seem to me to contribute to the difference between making a standard good or poor. However, often enough a choice between two competing notations, e.g. between The ISO 8601 profile gate
The "gate" I had in mind was, above all, a conceptual one. That is, whether a candidate rule/feature (like permitting seasons in intervals) would count as being a part of an ISO 8601 profile or not. And I think it is neither desirable, nor feasible, to try to avoid an undesirable sociological consequences from ISO (like their refusing to register our ISO 8601 profile us in their database; or, worse, their asking us to take our standard off the internet for copyright reasons), by trying to lay low (e.g. by not drawing their attention by not asking for registration of our ISO 8601 profile). For one thing that strategy is abandoning your earlier ambitions to "sail under the “ISO 8601” flag, and [leverage] its prestige". For another, if we are successful in attracting widespread adoption, a goal you assumed most of us shared, our standard will come to their notice. I think we'd want to register our ISO 8601 profile if and when they set up their database. Lying in the grass, thinking about ways to make your option 2 (stipulate our standard as being an ISO 8601 profile even if it permits a few non-conforming rules) work, I wondered whether my interpretation of what counted as an ISO 8601 profile was wrongly strict. That is, I wondered whether the authors of the definition of an ISO 8601 profile, in enumerating the kinds of things you could do (CLARIFY and DELETE), intended for that enumeration to be non-exhaustive. In other words, I wondered whether given that the definition of an ISO 8601 profile doesn't expressly forbid EXTENDING and CONTRADICTING, then EXTENDING and CONTRADICTING might be permitted. However, on reading "Annex B (normative) ISO 8601 profiles" (ISO 8601-2:2016(2),pp 26-27) I think that interpretation implausible. It seems clear enough that the chief intention for ISO 8601 profiles is to provide subsets of the whole ISO 8601:201x (with allowances for CLARIFICATION where ISO 8601:201x isn't properly robust). Moreover, above trying to divine the author's intentions I think ISO 8601 profiles would, of conceptual necessity, need to chiefly be about subsetting the whole. For the point of ISO 8601 (or any other competing Datetime format standard) is to limit the range of possible formats deployed in the world. And so I think I'm motivated to support the subsetting property of ISO 8601 profiles. In other words, if I was on the ISO committee and somebody suggested that ISO 8601 profiles permitted EXTENSIONS and CONTRADICTS I'd argue against it (albeit while also wanting to make it clear that a standard that was EXTENDING and CONTRADICTING wouldn't be pursued for copyright infringement). In more other words, even if ISO never came back to us with adverse sociological consequences it seems we'd be undermining the integrity of the concept of ISO 8601 profiles if we, under option 2, were attempting to smuggle things in that weren't strictly ISO 8601 profile conforming. That would seem likely to have the adverse sociological consequence of confusing the readers of our standard. Although you weren't doing so in your immediately prior post, if you wanted to push back on my arguments here, and further defend option 2, then I'd continue to welcome it. But on my current line of thinking, instead of option 2, it would be far better to either:
Option 3: Our standard as a (strictly conforming) ISO 8601 profile
Yes, that seems quite possible. Even assuming we could convince ourselves that seasons in ranges was ambiguously an EXTENSION or a CLARIFICATION, contrary to @inukshuk’s current view, and that we could therefore stipulate it as a CLARIFICATION, in order for it to count as being part of (strictly conforming) ISO 8601 profile, then ... ISO could update its standard to make it clear that seasons in ranges are invalid. In that case, under option 3, we'd have to jettison seasons in ranges. And, it seems quite plausible, that their might be a few candidate features like this - beyond what we can enumerate now. I worry about future discoveries. If we are to abandon our right to EXTENSIONS and CONTRADICTIONS it might be better not to bother with our Standards effort all ... and just adopted EDTF:ISO. Option 4
Given your use of "this profile" in the second paragraph you might have in mind the whole of our standard be regarded as an ISO 8601 profile. Under this interpretation this just looks like option 2. Alternatively, given your "a strictly conforming ISO 8601 profile, combined with", you might have in mind that a strictly conforming ISO 8601 profile will be a subset of our standard. I think this is more likely to be your intended meaning, but under this interpretation this just looks like option 1. My subtitle was "containing an ISO 8601 Profile plus extensions and contradictions". The "plus" was meant to demarc separate entities on either side that, taken together, comprise our standard. That is, so our standard was not an ISO 8601 profile although it contained one. |
|
@njbart By the way, from "B.3 Generalizing the concept of an ISO 8601 profile" (ISO 8601-2:2016(2), p 26), having the section you've previously quoted, my attention has rested for a while on the first clause ...
That gives rise to two thoughts:
|
|
Bump for @njbart, @plk, @inukshuk, and @moewew. Have you seen JohnLukeBentley/open-datetime-standard-bootstrap To save you having to read the whole thread. I'm essentially wanting to know if BibliographicDatetimeFormat.pdf (direct download) looks worth developing. It would be better to reply in that thread. |
The Proposal
Intro
I (@JohnLukeBentley) propose that we create an "Open Datetime Format: containing an ISO 8601 Profile plus extensions and contradictions". "Open Datetime Format" or "ODF", for short.
At least for the present discussion I'm using "datetime" as a generic term. That is, so that "2018-02-01", "20:30", and "2018-02-01 20:30" are all examples of a "datetime".
About ISO 8601:201x
ISO 8601:201x is the latest datetime format from the International Standards Organisation (ISO). It comes in two parts:
ISO 8601:201x is an update of ISO 8601:2004.
ISO 8601:201x is currently in draft and it seems to be nearing publication. See the "life cycle" timeline tracker at the bottom of the page from either of those above links. At http://www.loc.gov/standards/datetime/pre-submission.html it is claimed that ISO 8601:201x is "to be published in 2018".
The version I have is ISO 8601:2016(e) dated 2016-10-26, as was recently available from http://www.loc.gov/standards/datetime/.
Containing an ISO 8601 profile
I propose the content of the Open Datetime Format will:
Contain an ISO 8601 profile that will, as far as possible, be based on and track the ISO 8601:201x Profile - Annex C The Extended Date/Time Format (from now on "EDTF:ISO"). The ISO 8601 profile within Open Datetime Format will:
... plus ...
"EXTEND" EDTF:ISO (or the larger ISO 8601:201x) where necessary, introducing datetime kinds where we think EDTF:ISO (and the larger ISO 8601:201x) should have included them (e.g. ISO 8601-201x doesn't mention seasons in date ranges. We might, therefore, include seasons in date ranges); and
"CONTRADICT" EDTF:ISO (and the larger ISO 8601:201x) where necessary (e.g. ISO 8601-201x uses "%" for uncertain and approximate dates. We might therefore continue with the traditional "?~").
That is, Open Datetime Format is not an ISO 8601 profile, it contains an ISO 8601 profile (of our own devising).
"CLARIFY", "DELETE", "EXTEND", "CONTRADICT", and their cognates ("CLARIFICATION", "DELETED", etc.) have their ordinary English meaning. But I have in mind to formally emphasize their use much like "MUST", "MUST NOT", etc. are in RFC 2119.
The Extended Date/Time Format in ISO 8601:201x Annex C (EDTF:ISO) is an evolution from The Extended Date/Time Format found at the Library of Congress (from now on "EDTF:LOC"): http://www.loc.gov/standards/datetime/ and http://www.loc.gov/standards/datetime/pre-submission.html.
EDTF:LOC was a standard built to serve the bibliographic community. However EDTF:LOC, EDTF:ISO, and the proposed Open Datetime Format, have (or will have) uses also in other communities/areas of application.
So the Open Datetime Format is intended to continue the work done started in EDTF:LOC folk and evolved in EDTF:ISO. In both cases very good work has been done to shape those standards.
Open/Free (at liberty)
I have in mind that The Open Datetime Format will be open in that:
But:
I'm not properly across the principles of ...
... and their respective licenses. So I'm currently unable to suggest a preference.
I know, at least, Richard Stallman (Free Software Foundation Founder) discourages the conflation of "open" and "free" (at liberty):
Until I get sharper handle on the distinction I'll remain guilty of using "open" to mean the same thing as "free" (at liberty).
Agreeing on the principles of openness or freedom will be very much up for debate and, in turn, the consequent license.
However, for above list of open ends it is intended that Github be the platform for developing the standard.
Clear and unambiguous
Open Datetime Format should be both unambiguous and clear to follow. That's a difficult goal. Both EDTF:LOC and EDTF:ISO reasonably approach that goal. But I have ambitions to be clearer than either.
Those ambitions are launched off the back of currently vague ideas like:
The text was updated successfully, but these errors were encountered: