-
-
Notifications
You must be signed in to change notification settings - Fork 315
Add formats "date" and "time" (or all RFC 3339 formats?) #199
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
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 |
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 |
@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:
Since |
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‘ |
Yeah supporting rfc3339 from Python should be trivial.
…On Aug 20, 2017 06:11, "Andreas Kuckartz" ***@***.***> wrote:
Those interested in LD compatible solutions might want to look at
‘dcterms:W3CDTF‘
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#199 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAUIXoZtTE3G64qswZBFTGHjy2PMdPtJks5saAZogaJpZM4LPS3Q>
.
|
@handrews There is no problem to implement, but I don't see the use case for anything but So if we add them, I would go with MAY if anything (to reserve them), not SHOULD. Maybe add |
@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
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. |
This addresses json-schema-org#199 by supporting the two least controversial and most requested addtional date/time formats, and reserving the remaining namespace while we decide whether or how to specify additional RFC 3339 formats.
Merged #399. |
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.
The text was updated successfully, but these errors were encountered: