json-schema icon indicating copy to clipboard operation
json-schema copied to clipboard

Handling of defaults in anyOf schemas

Open RST-J opened this issue 11 years ago • 13 comments

Caused by the discussion in #181 I think we need to explicitly define respectively document (if the existing behavior is what we decide to go for), how the default keyword is handled in anyOf schemas because the spec does not say anything about it.

RST-J avatar Nov 23 '14 23:11 RST-J

Should the discussion be here? Or in the common test suite?

In fact if it's not clearly defined in the Json schema spec then it should be there. But the common test suite is the second best place.

My concern would be that we could implement a solution that's later deemed to be incorrect=

iainbeeston avatar Nov 24 '14 07:11 iainbeeston

I've just double checked the spec (for my own sanity), and it only describes default values on properties, but doesn't explain what should happen within any of, all of etc. I'll raise a pull request on common test suite and start the discussion

iainbeeston avatar Nov 24 '14 08:11 iainbeeston

I agree that we should bring this topic to the common test suite, first because of your argument and second because all implementations are concerned and it would be great to be compatible to each other. It would be nice if you link the discussion over there in this issue. Once there is a decision for the common test suite and after we adhere to that we can close this issue.

RST-J avatar Nov 24 '14 13:11 RST-J

I've just re-read the RFC, and nowhere does the json schema spec say that default values should be inserted in the original json. Admittedly it's very vague, but here's what it says:

6.2.  "default"

6.2.1.  Valid values

   There are no restrictions placed on the value of this keyword.

6.2.2.  Purpose

   This keyword can be used to supply a default JSON value associated
   with a particular schema.  It is RECOMMENDED that a default value be
   valid against the associated schema.

   This keyword MAY be used in root schemas, and in any subschemas.

If I was implementing a new json schema validator from the spec, I would assume that the default values are only used during validation. I suspect that if we do not update the original json with the default values, then the whole problem of how to handle defaults in subschemas goes away.

iainbeeston avatar Nov 24 '14 21:11 iainbeeston

Reconsidering this we should maybe, at least starting with v3, completely ignore defaults because they are defined as "default": {} which means anything is allowed. The spec only recommends but not requires validity in the context of the associated schema (I doubt that this is even expressible by the means of the spec). I found this thoughts by searching for how other implementations handle this and this reasoning suggests to leave defaults untouched - even for validation itself.

I think validation is/should be an idempotent operation and so I agree to not insert defaults. Whether to use defaults for validation or not seems to be a design decision to me and I see valid arguments for both cases. Maybe we should provide a flag that indicates how to proceed with them.

RST-J avatar Nov 24 '14 22:11 RST-J

Yeah, apparently so:

https://github.com/json-schema/JSON-Schema-Test-Suite/pull/67

The common test suite guys say that defaults shouldn't even be used during validation...=

iainbeeston avatar Nov 25 '14 07:11 iainbeeston

Well, there is the MAY keyword, so we can choose how to handle them. I think we have consent to not insert them anymore. But what about the idea of a flag that indicates whether to consider them during validation?

RST-J avatar Nov 25 '14 07:11 RST-J

Yeah, maybe that's a good way of preserving the existing behaviour (in an opt-in way).

Part of me thinks that if defaults have no action then it'd be nice to remove that code altogether, in the hope it makes future maintenance easier. It also would solve the problem of defaults inside allOf!=

iainbeeston avatar Nov 25 '14 07:11 iainbeeston

Yes, we should remove that code then. The only thing that would need to remain (for if defaults should be considered during validation) is inserting the default value in a copy of the current data before it is passed to validation. What to do about contradictory defaults in anyOf is up to the user in either case, so that should work.

RST-J avatar Nov 25 '14 11:11 RST-J

But we should only insert defaults if the user passes in a flag (not by default) right?=

iainbeeston avatar Nov 25 '14 12:11 iainbeeston

Yes, I think opt-in is the better choice.

RST-J avatar Nov 25 '14 13:11 RST-J

Ok, so they have accepted your PR and there will be tests that require defaults to be ignored by default. So when I have time I'll work on this from time to time.

To be clear about what we want:

  • completely ignore defaults by default
  • a flag that indicates to consider defaults during validation

The question here is, do we want that flag to be an option which can either tell to consider defaults or also inserting them?

Edit: What about allOf? I'd suggest to simply insert every default from every schema (if passed) and clearly state in the docs that this may lead to data which will not revalidate. Actually this may be the case for simple defaults also, so this shouldn't be a real problem.

RST-J avatar Mar 11 '15 22:03 RST-J

Yes I agree with what you said.

My preferred option would be to pull out inserting defaults completely (less code to maintain) but that might be irritating for anyone relying on the current functionality.

iainbeeston avatar Mar 12 '15 06:03 iainbeeston