Add formats "date" and "time" (or all RFC 3339 formats?)
JonAnders opened this issue · comments
The current draft specifies "date-time" as a format attribute. A related and very useful extension of this would be to add "date" and "time" separately as well. These would be defined as the "full-date" and "full-time" specified in RFC 3339 section 5.6, the same section as where the "date-time" format is specified.
The "date" and "time" formats were part of the original draft, but were removed in draft v4. This comment by author of draft v4 however, seems to indicate that these shouldn't have been removed and should be re-introduced: java-json-tools/json-schema-validator#103 (comment)
Just to be clear, I don't believe the list of supported formats should be a huge list of every thinkable format that might be useful for someone. But I think that the three formats of "date", "time" and "date-time" are so closely related that either all of them should be supported or none.
Also, implementing "date" and "time" should be a small task for implementers of validators, especially if the "date-time" format is already supported.
I like this idea.
many validators already support them btw, so adding to spec is a good idea
I am also in favor. I want to avoid format proliferation, but completing the logical sets of things that are already in format (e.g. from the same RFCs like these from RFC 3339 or that are used in JSON Schema itself like "jsonpointer" and "uritemplate") seems like a good idea.
And @epoberezkin's point about existing support is a very strong indicator of utility.
I would suggest that perhaps the full format list in Section 5.6 be included to bring the draft into congruency with the RFC.
@moderndeveloperllc it seems a bit overkill, it's 12 things most of which exist primarily for ABNF rather than having individual value... Also I think consistency with the existing usage practice ("date" and "time" rather than "full-date" and "full-time") is more important.
@handrews I actually thought "date" and "time" would be in draft-06 but I guess they were out of scope. There is no rush to include them given an optional nature of format, we can stabilise formats in the next draft.
@epoberezkin I considered it but didn't want to delay Draft 06 with a debate on how many of the RFC formats to put in :-)
If @awwright is OK with throwing in "date" and "time" (matching "full-date" and "full-time" respectively) then I'd be fine with that. If we don't have consensus on which formats to add, I'd rather work it out for the next draft. We're very close to finishing draft 06 and I really don't want to delay it further.
@epoberezkin Unfortunately if you start deviating from the naming conventions, you run into the case where the draft only vaguely follows the RFC, as it doesn't include all the formats, and renames a few of them. This could cause more confusion than a handful of extra formats.
If @awwright doesn't think it prudent to stick with full-date and full-time, I would suggest removing the reference to RFC 3339 entirely and specifying the formats directly. That would allow using whatever format names desired without causing confusion by referencing an RFC that's only partially adhered to.
I don't have a particularly strong opinion about the "full-" prefix. I think there are too many possibilities here to resolve within the next few days, so I think this is for Draft 07, not 06.
@handrews I agree, let's table it
@handrews Do you know of a roadmap for when 07 items will be reconsidered :-) FWIW, I've started to come around to the idea of just date and time without the prefix. Most validators I've checked out use those - if they do anything other than date-time. This is especially prevalent on the JS form builders I've seen as it makes it more straightforward to generate HTML5 tags from schema.
@moderndeveloperllc we've been focusing on resolving some things with Hyper-Schema to get draft-06 out the door. There is only one PR still open for that so hopefully the draft will get published by next week and we can start working on draft-07.
OK, so I can see three options here:
-
Support all RFC 3339 date and time formats with the names used in the ABNF. I would write this up by changing the existing
"date-time"section to a'RFC 3339 date and time formats'section. This would reduce clutter by not re-enumerating each format. -
Support only
"date"and"time"(alongside the existing"date-time", defined as matching"full-date"and"full-time" -
Do both. Reference the list of formats in RFC 3339 and define
"date"and"time"as convenience aliases.
Since "format" is optional anyway, I lean towards number 3, but since format is also extensible, I don't feel super-strongly about it :-)
Number 3 would mean fewer BC breaks for existing libraries. It would also allow authors the option of parsing more formats, or just sticking with the status quo and supporting a majority of the use cases.
Regarding 1 and 3, I am curious how much work implementers think it will be to implement all of RFC 3339? That RFC also includes less common things like durations and periods.
@epoberezkin and @Julian can perhaps comment on the implementation burden. I would assume it would be deferred to some library that already implements it. It's not like it's a new cutting edge standard that no one uses yet :-D
The current guidance on formats is that if an implementation supports format at all, it SHOULD implement all of the listed formats. Which is fairly strong but not an absolute requirement.
We could also include a relatively limited set in the SHOULD, and indicate that implementations MAY support all of the RFC 3339 formats, and that any implementation that supports those format names MUST implement them in an RFC 3339-compliant way.
That would prevent actively incompatible implementations, while making the most essential one more likely to be supported.
I'm not necessarily advocating that, just brainstorming possible options.
Those interested in LD compatible solutions might want to look at ‘dcterms:W3CDTF‘
@handrews There is no problem to implement, but I don't see the use case for anything but date/time. The names in https://tools.ietf.org/html/rfc3339#section-5.6 are just for ABNF - I don't really think there is a value in them as formats.
So if we add them, I would go with MAY if anything (to reserve them), not SHOULD.
Maybe add date/time in 07 and think a bit more about the rest?
@epoberezkin I see your point, although I see use cases for most of them. The individual date an time pieces would be relevant for situations where these things are entered and stored individually.
For instance, at comics.org we have several fields that take year, month, and day separately, because often the complete date is not known (dodgy publishers messing with WWII-era paper rations weren't big on precise records :-) I would use date-fullyear, date-month, and date-mday were I writing a schema for that project.
partial-time is often used in context where the time zone is unimportant or known to always be the same.
I'm not saying that means we have to include all of these (although MAY for reserving is a good option), but I do see use cases from actual work that I've done for most of the names.
OK I think once I start looking at format (after getting Hyper-Schema as far along as I can), I am going to go with reserving the whole namespace and encouraging support with MAY, including the "date" and "time" aliases, but applying the SHOULD only to "date", "time", and "date-time".
Perhaps also a cref note in the XML that the MAY recommendation might be dropped entirely or become a SHOULD depending on what feedback, if any, we get.
While I find my own use cases fairly compelling (weird, right?), I do see @epoberezkin point. This seems like a reasonable way to split the difference and put this out in the wild to see what happens.
If @epoberezkin or anyone else thinks that's a really bad idea, do speak up.
Merged #399.
I am probably far too amused that RFC 3339 was implemented by PR 399. I blame lack of sleep :-P