-
-
Notifications
You must be signed in to change notification settings - Fork 32
OneOf/required schema validation issue #167
Comments
Thanks for reporting this. I'll set up a test to try and replicate it. I agree with your assessment. The JSON instance should fail. |
I've been able to replicate a problem, but it's not the same thing you're getting. For me it properly returns invalid, but for the wrong reason. I'll upload my branch and provide a link here to make sure what I'm doing matches what you think it should. |
The test looks good.
What error are you getting? I assume the error that should be returned is a oneOf for the xyz schema not being satisfied. I didn't get any error in my case; loaded a schema from a file (not exactly the one posted above but with same structure), and validated a JSON against the schema. |
For me, it was saying that both of the subschemas returned valid, which was also wrong. The bug I found was that Fixing this, both of the subschemas return invalid, and the |
Look forward to the fix. I had an issue while using "propertyNames" with "allOf"/"anyOf" but it might be due to this bug. I will give that a try when this fix is published. If it something different, could raise another bug/issue. |
Actually, if you can post an example of that, I can verify it works before publishing. |
Ok. A bit long, hopefully explains the point:
ii) Should be valid (one of A or B)
iii) Should be valid (one of A or B)
iv) Should be invalid (only one of A or B )
v) Should be invalid (field1 is missing)
From my tests, the invalid scenarios were not caught with the validation. |
I think you may be missing a level in the schema. Are Also, I'm concerned that this part {
"$ref": "#/definitions/fields",
"required": [
"field1"
]
} won't work as you expect. The spec requires that {
"allOf": [
{ "$ref": "#/definitions/fields" },
{
"required": [
"field1"
]
}
]
} |
fields, xyzBaseFieldNames define property names. Also the xyz JSON is not marked as invalid with a missing worldwide even with the allOf definition. This should not be the case. Your modification for the $ref should be fine since it ensures "field1" is enforced as a required property. |
I'm having trouble constructing this schema due to the missing parts. Could you please post a full schema (or edit the above)? For instance, if |
Ok here is the whole correct schema and samples:
ii) valid
iii) valid
iv) invalid (only one of A or B)
v) invalid (missing field1) i.e correct combination of field2 or A or B, without field1
The propertyNames in the allOf worldwide ensures no additional properties can be included. I checked the schema and sample validation here: JSON schema validator |
Yes, all of these validate properly with the new version. I'll publish shortly. Thanks for your help. |
Given this schema:
And this JSON:
I expected the validation to return an error because one of the required fields (B or C) is not present in the JSON. The idea is to have one of B or C.
However, this is not the case. The Validate method validates this JSON with no error. This is with version 9.9 of the library.
The text was updated successfully, but these errors were encountered: