Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Strings/arrays should still be allowed in "dependencies" #37

Closed
geraintluff opened this Issue · 13 comments

4 participants

Geraint Francis Galiegue Nick Lombard Andrei Neculau
Geraint
Collaborator

Version 3 allows the member values of "dependencies" to be strings. In this case, they represent a key which must also be present in the member object.

It also allows the member values of "dependencies" to be an array, representing a list of keys which must be present.

However, neither of these are present in the proposal that @fge wrote. I would like them both back, because they're useful and concise. :)

Geraint
Collaborator

It is possible to replicate the functionality using schemas and "required", like so:

{
    "dependencies": {
        "lastName": {
            "required": ["firstName"]
        },
        "middleName": {
            "required": ["firstName", "lastName"]
        }
    }
}

But I think being able to use strings/arrays is better. It's shorter, and easier to read:

{
    "dependencies": {
        "lastName": "firstName",
        "middleName": ["firstName", "lastName"]
    }
}

(btw, I'm aware that "middleName" only needs to rely on "lastName" in that example - it's just an illustration)

Francis Galiegue

Well, my objective was to simplify these, and if this is re-introduced, the "dependencies" keyword once again becomes a complicated mess...

Geraint
Collaborator

I see - I disagree, and I'd rather you didn't remove the functionality.

I think it's convenient and concise, and it's honestly not that hard to implement.

Francis Galiegue

Oh well, OK, I lose that one, but how about instead of a single string argument, only an array of strings are allowed, with at least one element? Ie, one would write:

{
    "dependencies": {
        "a": [ "b" ]
    }
}

instead of:

{
    "dependencies": {
        "a": "b"
    }
}

As to "not that hard", it depends on whom you ask ;) for people doing schema syntax validation as well as instance validation, "dependencies" is the worst keyword to validate in draft v3. For draft v4, my objective was to make things much easier.

Geraint
Collaborator

I was curious, so I had a look at DraftV?DependenciesSyntaxChecker and DraftV?DependenciesKeywordValidator (v3 and v4 versions).

I can see how disallowing arrays and strings saves you some complication - you don't have to check "simple dependencies" at all. However, I don't see any real advantage in just banning strings - it looks to me like it would save you a couple of lines of code, at best.

For me, I think that being able to write "b" instead of [ "b" ] is actually quite big for readability. I think it's similar to the type keyword - when there's only one of them, it seems a bit convoluted to write it in an array of length 1. For me, I think "ease of writing schemas" is more important here - as JSON Schema takes off, I'd hope that the people using/writing schemas vastly outnumber the people like you or me writing tools.

So if you are seriously keen on removing support for string (or array) values in dependencies, then I think we should ask around (perhaps in the Google Group) to see if anyone's actually using them. However, I was using both of these, so I'd rather they weren't removed without a discussion.

Francis Galiegue

I am not seriously keen about it, to be really honest, but one of my goals was to simplify implementations as well. Also, I personally don't have a use for "property dependencies" and have not seen real world usages of it except in... The metaschema itself (wrt m{ax,in}imum and exclusiveM{ax,in}imum). Not to mention that these can be emulated just as you mentioned above.

I agree that this should go through the Google Groups with all three suggestions:

  • keep draft v3 definition;
  • remove string values (replaceable with single element array);
  • remove property dependencies altogether.
Geraint
Collaborator

Sounds reasonable to me.

Although I think string/array dependencies is concise (which is important) I don't mind it going if I'm the only one using it. I just hadn't realised it was being removed - I thought your re-write was mostly restructuring, so I hadn't checked for features disappearing.

Nick Lombard
Owner

What about a separate document dealing with dependencies?

I agree with @fge that it is making things more complicating.
I also agree with @geraintluff that this is a requirement but in a separate document we can give it the required attention and maybe flesh it out some more.

Some additions that may be fruitful.

  • Province city type dependencies where list b is dependent on list a indek 1
  • multiple values, all or some as well as single selection
  • what about disqualifiers ie a and b but not c
  • dependency based on value ie "view_r_rated": "age > 18"

A separate spec allows us to flesh these out everyones satisfaction, simplifies referencing the information when you are concerned with this type of functionality, schema core is valid without it added while removing any hesitations to accept core due to outstanding issues with other concepts.

I would like to see these specs get accepted with no hiccups, this is going to raise many issues if not dealt with.

Your thoughts?
I can do a bit of research and see what comes out of pandoras box and start drafting a document to facilitate further discussions if you agree with this strategy.

Andrei Neculau

Has anyone considered just making "dependencies" described as

{
  "dependencies": {
    "a": ["b"],
    "c": ["d", "e"]
  }
}

simple for machines,
a lil' bit more boilerplate for humans, but still much better than the solution with "required"

I also like the fact that the property is named dependencies, and thus "a has as dependencies a list made out of b", "c... out of d, e" comes natural

Edit: it was mentioned #38 (comment)

Geraint
Collaborator

@andreineculau Yeah, @fge mentioned that above.

I'd be OK with that. I also think it reads more intuitively without needing the required keyword.

Although being able to use strings as well would be convenient, I don't think I'd miss it terribly. The required keyword also has to be an array (even when there's only one required property), and requiring the same for dependencies is at least consistent.

Francis Galiegue

OK, is there a compromise on an array of strings, then? With the constraints that there must be at least one element and that all elements be unique?

Andrei Neculau

I'm game with your definition, @fge

Francis Galiegue

See #42

Francis Galiegue fge closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.