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

Removing dependencies? #442

Closed
epoberezkin opened this Issue Oct 14, 2017 · 8 comments

Comments

Projects
None yet
4 participants
@epoberezkin
Member

epoberezkin commented Oct 14, 2017

@handrews could you please point me to the discussion about adding the note about the possibility of removing dependencies?

If it wasn't discussed, I would propose to remove this note from the spec until such possibility is agreed.

Without "dependencies", a concise schema:

{
  "dependencies": {
    "foo": ["bar"],
    "baz": ["quux"]
  }
}

will have to be replaced with:

{
  "allOf": [
    {
      "if": {"required": ["foo"]},
      "then": {"required": ["bar"]},
    },
    {
      "if": {"required": ["baz"]},
      "then": {"required": ["quux"]},
    }
  ]
}

which seems both more verbose and more difficult to understand.

So I am not sure what could be the motivation to remove it.

@handrews

This comment has been minimized.

Show comment
Hide comment
@handrews

handrews Oct 14, 2017

Member

You were the one who OK'd it:
#180 (comment)

The reason for putting the comment in is to provoke reactions from people who are actually using the keyword and want to keep it. The note is doing what it is intended to do. It is not in any way a commitment to removing the keyword.

I'm closing this not because your objections aren't useful (they are, and I've noted the point), but because I want people other than the usual suspects to file objections. That works better if they can't find one that's already open :-)

Member

handrews commented Oct 14, 2017

You were the one who OK'd it:
#180 (comment)

The reason for putting the comment in is to provoke reactions from people who are actually using the keyword and want to keep it. The note is doing what it is intended to do. It is not in any way a commitment to removing the keyword.

I'm closing this not because your objections aren't useful (they are, and I've noted the point), but because I want people other than the usual suspects to file objections. That works better if they can't find one that's already open :-)

@handrews handrews closed this Oct 14, 2017

@handrews

This comment has been minimized.

Show comment
Hide comment
@handrews

handrews Oct 15, 2017

Member

Thinking on this a bit more, it's really the schema form of dependencies that I would prefer to remove. I agree that the property name form is a nice shortcut. But I don't think that "if": {"required": ["foo"]} on its own, with an arbitrary then, is worth having a shortcut for.

Or if it is, I really don't like having the same keyword used for the string and schema forms. They're not really the same thing and it's hard to reason about the keyword as it can be either a subschema keyword or a value keyword which is weird.

Member

handrews commented Oct 15, 2017

Thinking on this a bit more, it's really the schema form of dependencies that I would prefer to remove. I agree that the property name form is a nice shortcut. But I don't think that "if": {"required": ["foo"]} on its own, with an arbitrary then, is worth having a shortcut for.

Or if it is, I really don't like having the same keyword used for the string and schema forms. They're not really the same thing and it's hard to reason about the keyword as it can be either a subschema keyword or a value keyword which is weird.

@handrews handrews reopened this Oct 15, 2017

@handrews

This comment has been minimized.

Show comment
Hide comment
@handrews

handrews Oct 15, 2017

Member

type has two forms, but both are value forms (single string vs array of strings). items has two forms, but both are subschema forms (single subschema vs array of subschemas).

dependencies has one value form and one subschema form. I think the value form is worth keeping, but I'd like to encourage removal of the subschema form in favor of if. Perhaps I could clarify the note in this manner?

Member

handrews commented Oct 15, 2017

type has two forms, but both are value forms (single string vs array of strings). items has two forms, but both are subschema forms (single subschema vs array of subschemas).

dependencies has one value form and one subschema form. I think the value form is worth keeping, but I'd like to encourage removal of the subschema form in favor of if. Perhaps I could clarify the note in this manner?

@epoberezkin

This comment has been minimized.

Show comment
Hide comment
@epoberezkin

epoberezkin Oct 15, 2017

Member

I agree about schema form, this one was a bit confusing indeed.

I think I meant schema form in that comment too ;)

Member

epoberezkin commented Oct 15, 2017

I agree about schema form, this one was a bit confusing indeed.

I think I meant schema form in that comment too ;)

@pipobscure

This comment has been minimized.

Show comment
Hide comment
@pipobscure

pipobscure Oct 18, 2017

I find the schema form very useful. Please let's not remove it. If anything let's remove the values form.

{ "foo": { "required": [ "bar" ] } }

isn't that much worse than

{ "foo": [ "bar" ] }

but replacing the schema version with a combination of allOf/anyOf/oneOf/if/then/else is much worse.

It's much clearer than if/then/else.

Side-jibe at if/then/else: These are a bad idea to begin with, but since they are not obligatory to use, I'm fine keeping them. One reason why they are bad is that they mutate JSON-Schema from a schema to a programming language.

pipobscure commented Oct 18, 2017

I find the schema form very useful. Please let's not remove it. If anything let's remove the values form.

{ "foo": { "required": [ "bar" ] } }

isn't that much worse than

{ "foo": [ "bar" ] }

but replacing the schema version with a combination of allOf/anyOf/oneOf/if/then/else is much worse.

It's much clearer than if/then/else.

Side-jibe at if/then/else: These are a bad idea to begin with, but since they are not obligatory to use, I'm fine keeping them. One reason why they are bad is that they mutate JSON-Schema from a schema to a programming language.

@handrews

This comment has been minimized.

Show comment
Hide comment
@handrews

handrews Oct 18, 2017

Member

One reason why they are bad is that they mutate JSON-Schema from a schema to a programming language.

This was covered in excruciating detail in #180, and will not be revisited until the keywords have been available in a published draft to see how they are or are not used "in the wild."

Member

handrews commented Oct 18, 2017

One reason why they are bad is that they mutate JSON-Schema from a schema to a programming language.

This was covered in excruciating detail in #180, and will not be revisited until the keywords have been available in a published draft to see how they are or are not used "in the wild."

@handrews handrews added this to the draft-future milestone Oct 18, 2017

@handrews handrews changed the title from Removing dependenices? to Removing dependencies? Oct 31, 2017

@markchart

This comment has been minimized.

Show comment
Hide comment
@markchart

markchart Nov 10, 2017

Although I am a big fan of "if","then","else" I would not care to lose (either form of) "dependencies". Some constraints may be expressed much more clearly using "dependencies" (just as some things are better expressed using "if","then","else" than tangled "xxxOf" clauses).

It is counterproductive to try to squeeze out all redundancies at the cost of clarity, not just of exposition but of intent.

markchart commented Nov 10, 2017

Although I am a big fan of "if","then","else" I would not care to lose (either form of) "dependencies". Some constraints may be expressed much more clearly using "dependencies" (just as some things are better expressed using "if","then","else" than tangled "xxxOf" clauses).

It is counterproductive to try to squeeze out all redundancies at the cost of clarity, not just of exposition but of intent.

@handrews

This comment has been minimized.

Show comment
Hide comment
@handrews

handrews Jun 14, 2018

Member

Based on feedback we opted to split dependencies into two keywords rather than remove it. This addressed the problematic aspects of the keywords without losing functionality.

The string array form is now requiredDependencies, while the schema form will either remain dependencies or become schemaDependencies (I lean towards the latter, as it makes compatibility easier by not changing an existing keyword- see #591 for discussion).

Member

handrews commented Jun 14, 2018

Based on feedback we opted to split dependencies into two keywords rather than remove it. This addressed the problematic aspects of the keywords without losing functionality.

The string array form is now requiredDependencies, while the schema form will either remain dependencies or become schemaDependencies (I lean towards the latter, as it makes compatibility easier by not changing an existing keyword- see #591 for discussion).

@handrews handrews closed this Jun 14, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment