Skip to content

some more tests for the "duration" format #402

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

Closed
wants to merge 1 commit into from

Conversation

karenetheridge
Copy link
Member

No description provided.

@karenetheridge karenetheridge requested a review from a team June 11, 2020 18:41
},
{
"description": "half a year duration, with full stop decimal point",
"comment": "ISO 8601 revision in year 2000 added decimals",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It doesn't seem like these apply, if I read the spec right. The spec says:

Date and time format names are derived from RFC 3339, section 5.6. The duration format is from the ISO 8601 ABNF as given in Appendix A of RFC 3339.

The ABNF there doesn't look like it allows these, no? The 2000 revision doesn't seem like it should apply.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it is more useful to include the modern spec than one that is 25+ years old (I believe RFC3339 is intending to reference ISO8601 as a whole, rather than redefining it with restrictions), but this is not a hill I want to die on. I'd ask @handrews to update the spec to include the latest ISO8601 revisions, but I doubt he wants to spend another minute more thinking about formats.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't necessarily disagree on the spec side, but the test suite isn't the place for innovation -- if the spec does mean to include this behavior then that's all fine and we should, but if not, we need to first update the spec, and then apply the behavior to the drafts it will (in the future) apply to.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(To be clear, I think the action item here is "find out whether the spec intends to include this or not" -- and if it doesn't, we have to axe these, and then we can both add the clarification to the next spec and then at that point add these then)

But probably also easier to merge all the other indisputable tests first, so might be good to again split this PR so that those can be merged. (Or otherwise we can just keep this open until we clarify?)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I created a ticket here -- json-schema-org/json-schema-spec#947 -- does this summarize the situation fully?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we split the PR in 2 some of these that aren't related to that ticket can get merged immediately if you want? Otherwise yeah we can just leave it until the spec addresses.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

agreed - pulled out into #412. I can rebase this PR later but will leave it alone for now so the conversation is not lost.

@Julian
Copy link
Member

Julian commented Jun 16, 2020 via email

@Julian
Copy link
Member

Julian commented Jul 29, 2020

@karenetheridge it sounds like frustration aside that upstream we may not all be in agreement about improvements to formats, that json-schema-org/json-schema-spec#947 (comment) is saying "the existing specs mean that BNF and no more", i.e. to close and leave these out (or to put them in a second iso8601duration file I guess is also something we can consider).

Do you agree?

@karenetheridge karenetheridge added the on hold changes that should not be applied just yet, but maybe later label Aug 5, 2020
@Julian
Copy link
Member

Julian commented Oct 4, 2020

@karenetheridge going to close this just to make ourselves look better (with 20 open PRs, oy...) -- I think we basically can't do anything here until/unless something changes in the spec. If that ever happens, obviously we should revisit.

@Julian Julian closed this Oct 4, 2020
@karenetheridge karenetheridge deleted the ether/more-format-duration branch April 1, 2021 23:06
@ChALkeR
Copy link
Member

ChALkeR commented Sep 20, 2021

Could this perhaps be landed without the exact tests that raised concerns?

@ChALkeR
Copy link
Member

ChALkeR commented Sep 20, 2021

Ah, sorry, that happened in #412.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
on hold changes that should not be applied just yet, but maybe later
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants