Skip to content
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

Revert PR#376. #559

Merged
merged 1 commit into from
Jun 25, 2022
Merged

Revert PR#376. #559

merged 1 commit into from
Jun 25, 2022

Conversation

karenetheridge
Copy link
Member

The final form of these files as merged into main is not at all what was
intended in the original PR, and the tests are not correct: originally, they
were tests taken from later drafts of keywords that were introduced in these
later drafts, but with all the results changed to 'true' in order to
demonstrate that the keywords were NOT recognized - that they were entirely
ignored. The tests were moved to optional/, apparently with the intent to
express that an implementation might wish to recognize those keywords anyway
(which seems odd, but could be worth a discussion to see if this would be
useful), but the results were never changed from being all 'true' back to the
actual true-or-false results as in the specification version where they were
introduced. Consequently they are not valid tests and should be removed.

The final form of these files as merged into main is not at all what was
intended in the original PR, and the tests are not correct: originally, they
were tests taken from later drafts of keywords that were introduced in these
later drafts, but with all the results changed to 'true' in order to
demonstrate that the keywords were NOT recognized - that they were entirely
ignored. The tests were moved to optional/, apparently with the intent to
express that an implementation might wish to recognize those keywords anyway
(which seems odd, but could be worth a discussion to see if this would be
useful), but the results were never changed from being all 'true' back to the
actual true-or-false results as in the specification version where they were
introduced. Consequently they are not valid tests and should be removed.
@Julian
Copy link
Member

Julian commented Jun 25, 2022

This is incorrect, the tests are correct as merged. Please read the comment I left on the PR, and feel free to respond to it.

@Julian
Copy link
Member

Julian commented Jun 25, 2022

The above explanation is elaborated on in #376 (comment). Closing, but follow up if this still isn't clear enough.

@Julian Julian closed this Jun 25, 2022
@karenetheridge
Copy link
Member Author

If they stay, the duplicate $id in the draft7 tests should be fixed. This is apparent as soon as anyone tries to run them.

@karenetheridge
Copy link
Member Author

Also -- these tests for draft2019-09 and later aren't optional if/when we put in an explicit $schema keyword. In those drafts, the tests are saying "we expect you to be following this exact dialect, with nothing extra", because we have a way of expressing that now.

@Julian
Copy link
Member

Julian commented Jun 25, 2022

If they stay, the duplicate $id in the draft7 tests should be fixed. This is apparent as soon as anyone tries to run them.

Great, let's fix that.

Also -- these tests for draft2019-09 and later aren't optional if/when we put in an explicit $schema keyword. In those drafts, the tests are saying "we expect you to be following this exact dialect, with nothing extra", because we have a way of expressing that now.

Please read my comments. That's not correct, at least not to my reading of the spec. If you disagree, cite where it says so. I noted that here.

@handrews
Copy link
Contributor

@karenetheridge I do think that @Julian is correct that extra keywords are still allowed and ignored, and the part of the spec he quoted indicates that. $vocabulary says what is being used, but not that only those vocabularies are being used. This was intentional to allow casually adding keywords in informal settings, without having to construct a vocabulary, assign a URI, etc.

@Julian
Copy link
Member

Julian commented Jun 25, 2022

Merging, and will send a new PR reverting the merge so we can discuss after these are backed out, if that's what'd be helpful.

@Julian Julian merged commit d3f5cd4 into main Jun 25, 2022
@Julian Julian deleted the ether/revert-pr-376 branch June 25, 2022 14:22
Julian added a commit that referenced this pull request Jun 25, 2022
The intent of them is *not* to express that an implementation might wish
to recognize these keywords.

The intent of them is precisely the same as the original intent -- to
allow an implementation to test itself for *not* recognizing new
keywords. Such an implementation should enable these tests, as it is
free to do so, and these tests will help ensure it does not accidentally
leak newer keywords backwards in time if it doesn't mean to.

All of the previous discussion was strictly centered on not putting
these in the required directory.

The reason is that all drafts *allow* implementations to add extra
keywords. So a compliant implementation may indeed decide it actively
*wants* to implement new keywords. Then this file would not help them,
and they wouldn't run it. They would presumably love a version of this
file that *did* contain all the future assertions as correct for future
drafts, and in the future we could provide one. But given no
implementations really do do this, at least as far as I'm aware, and
given that this version of the file is here and written and more common,
it would seem perfectly reasonable to have it and hope for the other
version if or when someone wants it.

Further discussion is in #383 and later #559.

This reverts commit f605fbf.
@Julian
Copy link
Member

Julian commented Jun 25, 2022

Let's discuss on #561 so we're not using a closed PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants