-
-
Notifications
You must be signed in to change notification settings - Fork 266
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
Clarify dependencies deprecation #444
Conversation
jsonschema-validation.xml
Outdated
misunderstood and seems to be rarely used. Depending on feedback | ||
with "if", "then", and "else", this keyword may well be removed in a | ||
future draft. | ||
there is any benefit in keeping the schem form of dependencies. It is |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
typo 'schem'
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! Fixed.
It is focused on the subschema form, not the string array form.
I find the schema form very useful. Please let's not remove it. If anything let's remove the values form.
isn't that much worse than
but replacing the schema version with a combination of It's much clearer than Side-jibe at |
@pipobscure I don't mind keeping both, although in this case it may be better to rename schema form as @handrews suggested, because "dependencies" really mean "properties that are required in case some property is present" (i.e., value form), not "an arbitrary schema to validate against" (which is better expressed with if/then implication).
We had a long discussion and agreed that if/then/else is boolean implication (that can be expressed via and/or/not) rather than imperative construct. There are quite a few languages that use if/then/else syntax to mean the same as ternary in JS, and not a control flow statement. |
@pipobscure yes this objection (raised primarily by me) was covered in excessive detail in #180. |
I'm going to merge this so that people who want to talk about why to remove or not remove |
It is focused on the subschema form, not the string array form.
This addresses #442.