Schema Draft v7 if statement is not informing error in detail











up vote
0
down vote

favorite












I'm trying to validate a required property with if statement in JsonSchema, but it isn't informing me the property's error in detail.



The validation has been made correctly, but the error don't specify the property and which validation failed.



It works for required properties in the root level of an object, but when I specify a required property inside an object, it just warn that the json doesn't match and specify the then or else schema's path.



Schema example:



{
"$schema": "http://json-schema.org/draft-07/schema#",
"type": "object",
"required": [
"name",
"partners"
],
"properties": {
"partners": {
"type": "array",
"items": {
"type": "object",
"if": {
"properties": {
"juridical": {
"type": "object"
},
"natural": {
"type": "null"
}
}
},
"then": {
"properties": {
"juridical": {
"required": [ "tradeName" ],
"properties": {
"tradeName": {
"type": "string"
}
}
}
}
},
"else": {
"properties": {
"natural": {
"required": ["name"],
"properties": {
"name": {
"type": "string"
}
}
}
}
}
}
}
}
}


Json example:



{
"name": "Joao",
"partners": [
{
"juridical": null,
"natural": {

}
},
{
"juridical": {
"tradeName": ""
},
"natural": null
}
]
}


It should warns that the first partner have the "name" required (Required properties are missing from object: name.), instead it only tell me: JSON does not match schema from 'else'..



With a simple schema like this it works as expected:



Schema example:



{
"if": { "properties": { "power": { "minimum": 9000 } } },
"then": { "required": [ "disbelief" ] },
"else": { "required": [ "confidence" ] }
}


Json example:



{ "power": 10000 }


I'm using JsonSchemaValidator.net to verify the results.










share|improve this question


















  • 1




    Why do you believe "It should warns that the first partner have the "name" required"? Is the error output documented?
    – Relequestual
    Nov 9 at 13:07















up vote
0
down vote

favorite












I'm trying to validate a required property with if statement in JsonSchema, but it isn't informing me the property's error in detail.



The validation has been made correctly, but the error don't specify the property and which validation failed.



It works for required properties in the root level of an object, but when I specify a required property inside an object, it just warn that the json doesn't match and specify the then or else schema's path.



Schema example:



{
"$schema": "http://json-schema.org/draft-07/schema#",
"type": "object",
"required": [
"name",
"partners"
],
"properties": {
"partners": {
"type": "array",
"items": {
"type": "object",
"if": {
"properties": {
"juridical": {
"type": "object"
},
"natural": {
"type": "null"
}
}
},
"then": {
"properties": {
"juridical": {
"required": [ "tradeName" ],
"properties": {
"tradeName": {
"type": "string"
}
}
}
}
},
"else": {
"properties": {
"natural": {
"required": ["name"],
"properties": {
"name": {
"type": "string"
}
}
}
}
}
}
}
}
}


Json example:



{
"name": "Joao",
"partners": [
{
"juridical": null,
"natural": {

}
},
{
"juridical": {
"tradeName": ""
},
"natural": null
}
]
}


It should warns that the first partner have the "name" required (Required properties are missing from object: name.), instead it only tell me: JSON does not match schema from 'else'..



With a simple schema like this it works as expected:



Schema example:



{
"if": { "properties": { "power": { "minimum": 9000 } } },
"then": { "required": [ "disbelief" ] },
"else": { "required": [ "confidence" ] }
}


Json example:



{ "power": 10000 }


I'm using JsonSchemaValidator.net to verify the results.










share|improve this question


















  • 1




    Why do you believe "It should warns that the first partner have the "name" required"? Is the error output documented?
    – Relequestual
    Nov 9 at 13:07













up vote
0
down vote

favorite









up vote
0
down vote

favorite











I'm trying to validate a required property with if statement in JsonSchema, but it isn't informing me the property's error in detail.



The validation has been made correctly, but the error don't specify the property and which validation failed.



It works for required properties in the root level of an object, but when I specify a required property inside an object, it just warn that the json doesn't match and specify the then or else schema's path.



Schema example:



{
"$schema": "http://json-schema.org/draft-07/schema#",
"type": "object",
"required": [
"name",
"partners"
],
"properties": {
"partners": {
"type": "array",
"items": {
"type": "object",
"if": {
"properties": {
"juridical": {
"type": "object"
},
"natural": {
"type": "null"
}
}
},
"then": {
"properties": {
"juridical": {
"required": [ "tradeName" ],
"properties": {
"tradeName": {
"type": "string"
}
}
}
}
},
"else": {
"properties": {
"natural": {
"required": ["name"],
"properties": {
"name": {
"type": "string"
}
}
}
}
}
}
}
}
}


Json example:



{
"name": "Joao",
"partners": [
{
"juridical": null,
"natural": {

}
},
{
"juridical": {
"tradeName": ""
},
"natural": null
}
]
}


It should warns that the first partner have the "name" required (Required properties are missing from object: name.), instead it only tell me: JSON does not match schema from 'else'..



With a simple schema like this it works as expected:



Schema example:



{
"if": { "properties": { "power": { "minimum": 9000 } } },
"then": { "required": [ "disbelief" ] },
"else": { "required": [ "confidence" ] }
}


Json example:



{ "power": 10000 }


I'm using JsonSchemaValidator.net to verify the results.










share|improve this question













I'm trying to validate a required property with if statement in JsonSchema, but it isn't informing me the property's error in detail.



The validation has been made correctly, but the error don't specify the property and which validation failed.



It works for required properties in the root level of an object, but when I specify a required property inside an object, it just warn that the json doesn't match and specify the then or else schema's path.



Schema example:



{
"$schema": "http://json-schema.org/draft-07/schema#",
"type": "object",
"required": [
"name",
"partners"
],
"properties": {
"partners": {
"type": "array",
"items": {
"type": "object",
"if": {
"properties": {
"juridical": {
"type": "object"
},
"natural": {
"type": "null"
}
}
},
"then": {
"properties": {
"juridical": {
"required": [ "tradeName" ],
"properties": {
"tradeName": {
"type": "string"
}
}
}
}
},
"else": {
"properties": {
"natural": {
"required": ["name"],
"properties": {
"name": {
"type": "string"
}
}
}
}
}
}
}
}
}


Json example:



{
"name": "Joao",
"partners": [
{
"juridical": null,
"natural": {

}
},
{
"juridical": {
"tradeName": ""
},
"natural": null
}
]
}


It should warns that the first partner have the "name" required (Required properties are missing from object: name.), instead it only tell me: JSON does not match schema from 'else'..



With a simple schema like this it works as expected:



Schema example:



{
"if": { "properties": { "power": { "minimum": 9000 } } },
"then": { "required": [ "disbelief" ] },
"else": { "required": [ "confidence" ] }
}


Json example:



{ "power": 10000 }


I'm using JsonSchemaValidator.net to verify the results.







json json.net jsonschema






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Nov 9 at 11:55









João Pedro

169513




169513








  • 1




    Why do you believe "It should warns that the first partner have the "name" required"? Is the error output documented?
    – Relequestual
    Nov 9 at 13:07














  • 1




    Why do you believe "It should warns that the first partner have the "name" required"? Is the error output documented?
    – Relequestual
    Nov 9 at 13:07








1




1




Why do you believe "It should warns that the first partner have the "name" required"? Is the error output documented?
– Relequestual
Nov 9 at 13:07




Why do you believe "It should warns that the first partner have the "name" required"? Is the error output documented?
– Relequestual
Nov 9 at 13:07












1 Answer
1






active

oldest

votes

















up vote
0
down vote













Basically, JSON document either validates against JSON schema or not. This logic goes down through all sub-schemas and conditionals.



The content of error messages depends on specific implementation of JSON Schema validator. The one you use comes from a specific provider. As pointed by Relequestal, you cannot expect specific type of error message handling from specific implementation, unless it's what the provider documentation describes.



How about filing a suggestion to authors of the validator you use about extending messages for if-then-else case, feeding in your case?



Alternative approach: As I understand, your goal is to get as much specific error information as possible with this specific validator. It is what it is, so an alternative schema might fit the goal. As JSON Schema itself is a JSON document, thus you may consider a workaround by naming nodes in Schema in some consistent manner and using one of logical operators ("anyOf" (logical OR), "allOf" (logical AND), "oneOf" (logical XOR) ) instead of if-then-else.



Please note: schema based validator, in case of "allOf", "anyOf", "oneOf" is expected to run through all schemas until the logical condition is satisfied.




  • "allOf" - will check always if JSON doc validates against all schemas
    (AND)


  • "anyOf" - will check if JSON doc validates at least against 1 schema
    (OR, so some validator implementations might stop checking after
    first positive result as it's sufficient to evaluate check against
    "anyOf" to true),


  • "oneOf" - will check always if JSON doc validates exactly against
    one of enlisted schemas by checking against all of them (XOR)



(see: https://json-schema.org/draft-07/json-schema-validation.html#rfc.section.6.7.1 )



Thus if validated instance doesn't match schemas in above cases, the validator implementation may produce some 'false positives' in terms of error messages, as it will enlist issues encountered vs all schemas. It simply can't read our minds and guess what we meant by providing specific JSON doc, so it throws all on us to judge and decide.



One of many solutions could be to define variants of "juridical" and "natural" and combine them logically into schemas as in your case it seems you expect:




either juridical is an object (+relevant constraints) AND natural is not an object or juridical is not an object and natural is an object
(+relevant constraints).




Alternative schema (please note the "examples" section containing some test JSON documents):



{
"$schema": "http://json-schema.org/draft-07/schema#",
"type": "object",
"required": [
"name",
"partners"
],
"properties": {
"partners": {
"type": "array",
"items": {
"type": "object",
"anyOf" : [
{"$ref" : "#/definitions/juridical-is-object-and-natural-is-null"},
{"$ref" : "#/definitions/juridical-is-not-an-object-and-natural-is-an-object"}
],
"required" : ["natural","juridical"]
}
}
},
"examples" : [
{
"name": "Joao",
"partners": [
{
"juridical": null,
"natural": {

}
},
{
"juridical": {
"tradeName": ""
},
"natural": null
}
]
},
{
"name": "Joao",
"partners": [
{
"juridical": null,
"natural": {
"name" : ""
}
},
{
"juridical": {
"tradeName": ""
},
"natural": null
}
]
},
{
"name": "Joao",
"partners": [
{
"juridical": null,
"natural": {

}
},
{
"juridical": {
"tradeName": ""
},
"natural": null
},
{
"juridical" : ,
"natural" : {}
}
]
}
],
"definitions" : {
"natural" : {
"is-object" : {
"type" : "object",
"required": ["name"],
"properties": {
"name": {
"type": "string"
}
}
},
"is-not-an-object" : {
"not" : { "type" : "object" }
},
},
"juridical" : {
"is-object" : {
"type" : "object",
"required": ["tradeName"],
"properties": {
"name": {
"type": "string"
}
}
},
"is-not-an-object" : {
"not" : { "type" : "object" }
},
},
"juridical-is-object-and-natural-is-null" : {
"properties" : {
"natural" : {"$ref" : "#/definitions/natural/is-not-an-object"},
"juridical" : {"$ref" : "#/definitions/juridical/is-object"}
},
},
"juridical-is-not-an-object-and-natural-is-an-object" : {
"properties" : {
"natural" : {"$ref" : "#/definitions/natural/is-object"},
"juridical" : {"$ref" : "#/definitions/juridical/is-not-an-object"}
}
},
}
}


Notes:



"not" : { schema } error message might be confusing for casual users, but it conforms to the spec: https://json-schema.org/draft-07/json-schema-validation.html#rfc.section.6.7.4



Update



As explained in comments, you are after error details. Given the constraints of the selected tool in terms of if-then-else error details for more complex schemas, did you try to reshape schema using different keywords to trigger as less overhead messages as possible?



Alternative schema 2



{
"$schema": "http://json-schema.org/draft-07/schema#",
"type": "object",
"required": [
"name",
"partners"
],
"properties": {
"partners": {
"type": "array",
"items" : {
"properties" : {
"natural" : {
"if" : { "type" : "object" },
"then" : { "required" : ["name"] },
"dependencies" : {
"name" : {
"properties" : {
"name" : {"type" : "string"}
}
}
}
},
"juridical" : {
"if" : { "type" : "object" },
"then" : { "required" : ["tradeName"] },
"dependencies" : {
"tradeName" : {
"propertyNames" : {
"enum" : ["tradeName"]
},
"properties" : {
"tradeName" : {"type" : "string"}
}
}
}
}
},
"anyOf" : [
{"$ref" : "#/definitions/natural-is-null-juridical-is-an-object"},
{"$ref" : "#/definitions/natural-is-an-object-juridical-is-null"}
]
}
}
},
"definitions" : {
"natural-is-null-juridical-is-an-object" : {
"properties" : {
"natural" : { "type": "null"},
"juridical" : { "type" : "object"}
}
},
"natural-is-an-object-juridical-is-null" : {
"properties" : {
"natural" : { "type": "object"},
"juridical" : { "type" : "null"}
}
},
},
"examples" : [
{
"name": "Joao",
"partners": [
{
"juridical": null,
"natural": {

}
},
{
"juridical": {
"tradeName": "",
},
"natural": null
},
{
"juridical" : {},
"natural" : {}
},
{
"juridical" : null,
"natural" : null
}
]
},
]
}





share|improve this answer























  • Before knowing about the if statement in json schema, I was trying to use these logical operators (anyOf, oneOf, allOf). The problem was that if the statement doesn't match, it shows errors to all objects, natural and juridical, at the same time. So, if some, any or all of the schemas doesn't match, it applies all the schemas for each partner, and show me the errors.
    – João Pedro
    Nov 18 at 11:04










  • My goal is to know when a field was informed or not. I'd like to have a specific error that a field is required, so I can save it in database and expose an endpoint to request missing fields of an entity. I implemented a solution with JSON Path, but it doesn't seem the right tool to validate required fields, mainly when I have to apply a validation logic like with partners, that sometimes is natural or juridical (I know that It is a bad contract design). So I crated a rule model that exists a pre JSON Path validator field, that if true applies other rules related.
    – João Pedro
    Nov 18 at 11:12










  • Well, then it seems you should file a ticket to validator authors in regards to if-then-else detailed message. And yes, logical operators - that's what I meant, it throws all of them on you, as in case of invalid object there's no telepathic prediction what the object requestor meant. YOu may also consider usage of "dependencies" - but it may force you to change model. Did you try using "dependencies" like: when juridical field appears, it is an object - make something required?
    – PsychoFish
    Nov 18 at 13:50










  • Just to follow up: in order to use "dependencies" on object level and/or "contains" at array level (or even tupletyped validation), you'd need to have additional conditions defined in this case. Are there any? E.g. does the table must contain at least one object with juridical or natural being not null? One of each kind? Or maybe they need to be present in some specific sequence in the table?
    – PsychoFish
    Nov 19 at 9:17










  • @JoãoPedro I've updated answer with another alternative schema, shaped to trigger as much unique meaningful errors as possible, given the constraint of the tool for if-then-else errors details. However there is one 'anyOf' and meaningfulness of error details is dependent on well naming nodes in 'definitions' sections.
    – PsychoFish
    Nov 19 at 21:06











Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53225270%2fschema-draft-v7-if-statement-is-not-informing-error-in-detail%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
0
down vote













Basically, JSON document either validates against JSON schema or not. This logic goes down through all sub-schemas and conditionals.



The content of error messages depends on specific implementation of JSON Schema validator. The one you use comes from a specific provider. As pointed by Relequestal, you cannot expect specific type of error message handling from specific implementation, unless it's what the provider documentation describes.



How about filing a suggestion to authors of the validator you use about extending messages for if-then-else case, feeding in your case?



Alternative approach: As I understand, your goal is to get as much specific error information as possible with this specific validator. It is what it is, so an alternative schema might fit the goal. As JSON Schema itself is a JSON document, thus you may consider a workaround by naming nodes in Schema in some consistent manner and using one of logical operators ("anyOf" (logical OR), "allOf" (logical AND), "oneOf" (logical XOR) ) instead of if-then-else.



Please note: schema based validator, in case of "allOf", "anyOf", "oneOf" is expected to run through all schemas until the logical condition is satisfied.




  • "allOf" - will check always if JSON doc validates against all schemas
    (AND)


  • "anyOf" - will check if JSON doc validates at least against 1 schema
    (OR, so some validator implementations might stop checking after
    first positive result as it's sufficient to evaluate check against
    "anyOf" to true),


  • "oneOf" - will check always if JSON doc validates exactly against
    one of enlisted schemas by checking against all of them (XOR)



(see: https://json-schema.org/draft-07/json-schema-validation.html#rfc.section.6.7.1 )



Thus if validated instance doesn't match schemas in above cases, the validator implementation may produce some 'false positives' in terms of error messages, as it will enlist issues encountered vs all schemas. It simply can't read our minds and guess what we meant by providing specific JSON doc, so it throws all on us to judge and decide.



One of many solutions could be to define variants of "juridical" and "natural" and combine them logically into schemas as in your case it seems you expect:




either juridical is an object (+relevant constraints) AND natural is not an object or juridical is not an object and natural is an object
(+relevant constraints).




Alternative schema (please note the "examples" section containing some test JSON documents):



{
"$schema": "http://json-schema.org/draft-07/schema#",
"type": "object",
"required": [
"name",
"partners"
],
"properties": {
"partners": {
"type": "array",
"items": {
"type": "object",
"anyOf" : [
{"$ref" : "#/definitions/juridical-is-object-and-natural-is-null"},
{"$ref" : "#/definitions/juridical-is-not-an-object-and-natural-is-an-object"}
],
"required" : ["natural","juridical"]
}
}
},
"examples" : [
{
"name": "Joao",
"partners": [
{
"juridical": null,
"natural": {

}
},
{
"juridical": {
"tradeName": ""
},
"natural": null
}
]
},
{
"name": "Joao",
"partners": [
{
"juridical": null,
"natural": {
"name" : ""
}
},
{
"juridical": {
"tradeName": ""
},
"natural": null
}
]
},
{
"name": "Joao",
"partners": [
{
"juridical": null,
"natural": {

}
},
{
"juridical": {
"tradeName": ""
},
"natural": null
},
{
"juridical" : ,
"natural" : {}
}
]
}
],
"definitions" : {
"natural" : {
"is-object" : {
"type" : "object",
"required": ["name"],
"properties": {
"name": {
"type": "string"
}
}
},
"is-not-an-object" : {
"not" : { "type" : "object" }
},
},
"juridical" : {
"is-object" : {
"type" : "object",
"required": ["tradeName"],
"properties": {
"name": {
"type": "string"
}
}
},
"is-not-an-object" : {
"not" : { "type" : "object" }
},
},
"juridical-is-object-and-natural-is-null" : {
"properties" : {
"natural" : {"$ref" : "#/definitions/natural/is-not-an-object"},
"juridical" : {"$ref" : "#/definitions/juridical/is-object"}
},
},
"juridical-is-not-an-object-and-natural-is-an-object" : {
"properties" : {
"natural" : {"$ref" : "#/definitions/natural/is-object"},
"juridical" : {"$ref" : "#/definitions/juridical/is-not-an-object"}
}
},
}
}


Notes:



"not" : { schema } error message might be confusing for casual users, but it conforms to the spec: https://json-schema.org/draft-07/json-schema-validation.html#rfc.section.6.7.4



Update



As explained in comments, you are after error details. Given the constraints of the selected tool in terms of if-then-else error details for more complex schemas, did you try to reshape schema using different keywords to trigger as less overhead messages as possible?



Alternative schema 2



{
"$schema": "http://json-schema.org/draft-07/schema#",
"type": "object",
"required": [
"name",
"partners"
],
"properties": {
"partners": {
"type": "array",
"items" : {
"properties" : {
"natural" : {
"if" : { "type" : "object" },
"then" : { "required" : ["name"] },
"dependencies" : {
"name" : {
"properties" : {
"name" : {"type" : "string"}
}
}
}
},
"juridical" : {
"if" : { "type" : "object" },
"then" : { "required" : ["tradeName"] },
"dependencies" : {
"tradeName" : {
"propertyNames" : {
"enum" : ["tradeName"]
},
"properties" : {
"tradeName" : {"type" : "string"}
}
}
}
}
},
"anyOf" : [
{"$ref" : "#/definitions/natural-is-null-juridical-is-an-object"},
{"$ref" : "#/definitions/natural-is-an-object-juridical-is-null"}
]
}
}
},
"definitions" : {
"natural-is-null-juridical-is-an-object" : {
"properties" : {
"natural" : { "type": "null"},
"juridical" : { "type" : "object"}
}
},
"natural-is-an-object-juridical-is-null" : {
"properties" : {
"natural" : { "type": "object"},
"juridical" : { "type" : "null"}
}
},
},
"examples" : [
{
"name": "Joao",
"partners": [
{
"juridical": null,
"natural": {

}
},
{
"juridical": {
"tradeName": "",
},
"natural": null
},
{
"juridical" : {},
"natural" : {}
},
{
"juridical" : null,
"natural" : null
}
]
},
]
}





share|improve this answer























  • Before knowing about the if statement in json schema, I was trying to use these logical operators (anyOf, oneOf, allOf). The problem was that if the statement doesn't match, it shows errors to all objects, natural and juridical, at the same time. So, if some, any or all of the schemas doesn't match, it applies all the schemas for each partner, and show me the errors.
    – João Pedro
    Nov 18 at 11:04










  • My goal is to know when a field was informed or not. I'd like to have a specific error that a field is required, so I can save it in database and expose an endpoint to request missing fields of an entity. I implemented a solution with JSON Path, but it doesn't seem the right tool to validate required fields, mainly when I have to apply a validation logic like with partners, that sometimes is natural or juridical (I know that It is a bad contract design). So I crated a rule model that exists a pre JSON Path validator field, that if true applies other rules related.
    – João Pedro
    Nov 18 at 11:12










  • Well, then it seems you should file a ticket to validator authors in regards to if-then-else detailed message. And yes, logical operators - that's what I meant, it throws all of them on you, as in case of invalid object there's no telepathic prediction what the object requestor meant. YOu may also consider usage of "dependencies" - but it may force you to change model. Did you try using "dependencies" like: when juridical field appears, it is an object - make something required?
    – PsychoFish
    Nov 18 at 13:50










  • Just to follow up: in order to use "dependencies" on object level and/or "contains" at array level (or even tupletyped validation), you'd need to have additional conditions defined in this case. Are there any? E.g. does the table must contain at least one object with juridical or natural being not null? One of each kind? Or maybe they need to be present in some specific sequence in the table?
    – PsychoFish
    Nov 19 at 9:17










  • @JoãoPedro I've updated answer with another alternative schema, shaped to trigger as much unique meaningful errors as possible, given the constraint of the tool for if-then-else errors details. However there is one 'anyOf' and meaningfulness of error details is dependent on well naming nodes in 'definitions' sections.
    – PsychoFish
    Nov 19 at 21:06















up vote
0
down vote













Basically, JSON document either validates against JSON schema or not. This logic goes down through all sub-schemas and conditionals.



The content of error messages depends on specific implementation of JSON Schema validator. The one you use comes from a specific provider. As pointed by Relequestal, you cannot expect specific type of error message handling from specific implementation, unless it's what the provider documentation describes.



How about filing a suggestion to authors of the validator you use about extending messages for if-then-else case, feeding in your case?



Alternative approach: As I understand, your goal is to get as much specific error information as possible with this specific validator. It is what it is, so an alternative schema might fit the goal. As JSON Schema itself is a JSON document, thus you may consider a workaround by naming nodes in Schema in some consistent manner and using one of logical operators ("anyOf" (logical OR), "allOf" (logical AND), "oneOf" (logical XOR) ) instead of if-then-else.



Please note: schema based validator, in case of "allOf", "anyOf", "oneOf" is expected to run through all schemas until the logical condition is satisfied.




  • "allOf" - will check always if JSON doc validates against all schemas
    (AND)


  • "anyOf" - will check if JSON doc validates at least against 1 schema
    (OR, so some validator implementations might stop checking after
    first positive result as it's sufficient to evaluate check against
    "anyOf" to true),


  • "oneOf" - will check always if JSON doc validates exactly against
    one of enlisted schemas by checking against all of them (XOR)



(see: https://json-schema.org/draft-07/json-schema-validation.html#rfc.section.6.7.1 )



Thus if validated instance doesn't match schemas in above cases, the validator implementation may produce some 'false positives' in terms of error messages, as it will enlist issues encountered vs all schemas. It simply can't read our minds and guess what we meant by providing specific JSON doc, so it throws all on us to judge and decide.



One of many solutions could be to define variants of "juridical" and "natural" and combine them logically into schemas as in your case it seems you expect:




either juridical is an object (+relevant constraints) AND natural is not an object or juridical is not an object and natural is an object
(+relevant constraints).




Alternative schema (please note the "examples" section containing some test JSON documents):



{
"$schema": "http://json-schema.org/draft-07/schema#",
"type": "object",
"required": [
"name",
"partners"
],
"properties": {
"partners": {
"type": "array",
"items": {
"type": "object",
"anyOf" : [
{"$ref" : "#/definitions/juridical-is-object-and-natural-is-null"},
{"$ref" : "#/definitions/juridical-is-not-an-object-and-natural-is-an-object"}
],
"required" : ["natural","juridical"]
}
}
},
"examples" : [
{
"name": "Joao",
"partners": [
{
"juridical": null,
"natural": {

}
},
{
"juridical": {
"tradeName": ""
},
"natural": null
}
]
},
{
"name": "Joao",
"partners": [
{
"juridical": null,
"natural": {
"name" : ""
}
},
{
"juridical": {
"tradeName": ""
},
"natural": null
}
]
},
{
"name": "Joao",
"partners": [
{
"juridical": null,
"natural": {

}
},
{
"juridical": {
"tradeName": ""
},
"natural": null
},
{
"juridical" : ,
"natural" : {}
}
]
}
],
"definitions" : {
"natural" : {
"is-object" : {
"type" : "object",
"required": ["name"],
"properties": {
"name": {
"type": "string"
}
}
},
"is-not-an-object" : {
"not" : { "type" : "object" }
},
},
"juridical" : {
"is-object" : {
"type" : "object",
"required": ["tradeName"],
"properties": {
"name": {
"type": "string"
}
}
},
"is-not-an-object" : {
"not" : { "type" : "object" }
},
},
"juridical-is-object-and-natural-is-null" : {
"properties" : {
"natural" : {"$ref" : "#/definitions/natural/is-not-an-object"},
"juridical" : {"$ref" : "#/definitions/juridical/is-object"}
},
},
"juridical-is-not-an-object-and-natural-is-an-object" : {
"properties" : {
"natural" : {"$ref" : "#/definitions/natural/is-object"},
"juridical" : {"$ref" : "#/definitions/juridical/is-not-an-object"}
}
},
}
}


Notes:



"not" : { schema } error message might be confusing for casual users, but it conforms to the spec: https://json-schema.org/draft-07/json-schema-validation.html#rfc.section.6.7.4



Update



As explained in comments, you are after error details. Given the constraints of the selected tool in terms of if-then-else error details for more complex schemas, did you try to reshape schema using different keywords to trigger as less overhead messages as possible?



Alternative schema 2



{
"$schema": "http://json-schema.org/draft-07/schema#",
"type": "object",
"required": [
"name",
"partners"
],
"properties": {
"partners": {
"type": "array",
"items" : {
"properties" : {
"natural" : {
"if" : { "type" : "object" },
"then" : { "required" : ["name"] },
"dependencies" : {
"name" : {
"properties" : {
"name" : {"type" : "string"}
}
}
}
},
"juridical" : {
"if" : { "type" : "object" },
"then" : { "required" : ["tradeName"] },
"dependencies" : {
"tradeName" : {
"propertyNames" : {
"enum" : ["tradeName"]
},
"properties" : {
"tradeName" : {"type" : "string"}
}
}
}
}
},
"anyOf" : [
{"$ref" : "#/definitions/natural-is-null-juridical-is-an-object"},
{"$ref" : "#/definitions/natural-is-an-object-juridical-is-null"}
]
}
}
},
"definitions" : {
"natural-is-null-juridical-is-an-object" : {
"properties" : {
"natural" : { "type": "null"},
"juridical" : { "type" : "object"}
}
},
"natural-is-an-object-juridical-is-null" : {
"properties" : {
"natural" : { "type": "object"},
"juridical" : { "type" : "null"}
}
},
},
"examples" : [
{
"name": "Joao",
"partners": [
{
"juridical": null,
"natural": {

}
},
{
"juridical": {
"tradeName": "",
},
"natural": null
},
{
"juridical" : {},
"natural" : {}
},
{
"juridical" : null,
"natural" : null
}
]
},
]
}





share|improve this answer























  • Before knowing about the if statement in json schema, I was trying to use these logical operators (anyOf, oneOf, allOf). The problem was that if the statement doesn't match, it shows errors to all objects, natural and juridical, at the same time. So, if some, any or all of the schemas doesn't match, it applies all the schemas for each partner, and show me the errors.
    – João Pedro
    Nov 18 at 11:04










  • My goal is to know when a field was informed or not. I'd like to have a specific error that a field is required, so I can save it in database and expose an endpoint to request missing fields of an entity. I implemented a solution with JSON Path, but it doesn't seem the right tool to validate required fields, mainly when I have to apply a validation logic like with partners, that sometimes is natural or juridical (I know that It is a bad contract design). So I crated a rule model that exists a pre JSON Path validator field, that if true applies other rules related.
    – João Pedro
    Nov 18 at 11:12










  • Well, then it seems you should file a ticket to validator authors in regards to if-then-else detailed message. And yes, logical operators - that's what I meant, it throws all of them on you, as in case of invalid object there's no telepathic prediction what the object requestor meant. YOu may also consider usage of "dependencies" - but it may force you to change model. Did you try using "dependencies" like: when juridical field appears, it is an object - make something required?
    – PsychoFish
    Nov 18 at 13:50










  • Just to follow up: in order to use "dependencies" on object level and/or "contains" at array level (or even tupletyped validation), you'd need to have additional conditions defined in this case. Are there any? E.g. does the table must contain at least one object with juridical or natural being not null? One of each kind? Or maybe they need to be present in some specific sequence in the table?
    – PsychoFish
    Nov 19 at 9:17










  • @JoãoPedro I've updated answer with another alternative schema, shaped to trigger as much unique meaningful errors as possible, given the constraint of the tool for if-then-else errors details. However there is one 'anyOf' and meaningfulness of error details is dependent on well naming nodes in 'definitions' sections.
    – PsychoFish
    Nov 19 at 21:06













up vote
0
down vote










up vote
0
down vote









Basically, JSON document either validates against JSON schema or not. This logic goes down through all sub-schemas and conditionals.



The content of error messages depends on specific implementation of JSON Schema validator. The one you use comes from a specific provider. As pointed by Relequestal, you cannot expect specific type of error message handling from specific implementation, unless it's what the provider documentation describes.



How about filing a suggestion to authors of the validator you use about extending messages for if-then-else case, feeding in your case?



Alternative approach: As I understand, your goal is to get as much specific error information as possible with this specific validator. It is what it is, so an alternative schema might fit the goal. As JSON Schema itself is a JSON document, thus you may consider a workaround by naming nodes in Schema in some consistent manner and using one of logical operators ("anyOf" (logical OR), "allOf" (logical AND), "oneOf" (logical XOR) ) instead of if-then-else.



Please note: schema based validator, in case of "allOf", "anyOf", "oneOf" is expected to run through all schemas until the logical condition is satisfied.




  • "allOf" - will check always if JSON doc validates against all schemas
    (AND)


  • "anyOf" - will check if JSON doc validates at least against 1 schema
    (OR, so some validator implementations might stop checking after
    first positive result as it's sufficient to evaluate check against
    "anyOf" to true),


  • "oneOf" - will check always if JSON doc validates exactly against
    one of enlisted schemas by checking against all of them (XOR)



(see: https://json-schema.org/draft-07/json-schema-validation.html#rfc.section.6.7.1 )



Thus if validated instance doesn't match schemas in above cases, the validator implementation may produce some 'false positives' in terms of error messages, as it will enlist issues encountered vs all schemas. It simply can't read our minds and guess what we meant by providing specific JSON doc, so it throws all on us to judge and decide.



One of many solutions could be to define variants of "juridical" and "natural" and combine them logically into schemas as in your case it seems you expect:




either juridical is an object (+relevant constraints) AND natural is not an object or juridical is not an object and natural is an object
(+relevant constraints).




Alternative schema (please note the "examples" section containing some test JSON documents):



{
"$schema": "http://json-schema.org/draft-07/schema#",
"type": "object",
"required": [
"name",
"partners"
],
"properties": {
"partners": {
"type": "array",
"items": {
"type": "object",
"anyOf" : [
{"$ref" : "#/definitions/juridical-is-object-and-natural-is-null"},
{"$ref" : "#/definitions/juridical-is-not-an-object-and-natural-is-an-object"}
],
"required" : ["natural","juridical"]
}
}
},
"examples" : [
{
"name": "Joao",
"partners": [
{
"juridical": null,
"natural": {

}
},
{
"juridical": {
"tradeName": ""
},
"natural": null
}
]
},
{
"name": "Joao",
"partners": [
{
"juridical": null,
"natural": {
"name" : ""
}
},
{
"juridical": {
"tradeName": ""
},
"natural": null
}
]
},
{
"name": "Joao",
"partners": [
{
"juridical": null,
"natural": {

}
},
{
"juridical": {
"tradeName": ""
},
"natural": null
},
{
"juridical" : ,
"natural" : {}
}
]
}
],
"definitions" : {
"natural" : {
"is-object" : {
"type" : "object",
"required": ["name"],
"properties": {
"name": {
"type": "string"
}
}
},
"is-not-an-object" : {
"not" : { "type" : "object" }
},
},
"juridical" : {
"is-object" : {
"type" : "object",
"required": ["tradeName"],
"properties": {
"name": {
"type": "string"
}
}
},
"is-not-an-object" : {
"not" : { "type" : "object" }
},
},
"juridical-is-object-and-natural-is-null" : {
"properties" : {
"natural" : {"$ref" : "#/definitions/natural/is-not-an-object"},
"juridical" : {"$ref" : "#/definitions/juridical/is-object"}
},
},
"juridical-is-not-an-object-and-natural-is-an-object" : {
"properties" : {
"natural" : {"$ref" : "#/definitions/natural/is-object"},
"juridical" : {"$ref" : "#/definitions/juridical/is-not-an-object"}
}
},
}
}


Notes:



"not" : { schema } error message might be confusing for casual users, but it conforms to the spec: https://json-schema.org/draft-07/json-schema-validation.html#rfc.section.6.7.4



Update



As explained in comments, you are after error details. Given the constraints of the selected tool in terms of if-then-else error details for more complex schemas, did you try to reshape schema using different keywords to trigger as less overhead messages as possible?



Alternative schema 2



{
"$schema": "http://json-schema.org/draft-07/schema#",
"type": "object",
"required": [
"name",
"partners"
],
"properties": {
"partners": {
"type": "array",
"items" : {
"properties" : {
"natural" : {
"if" : { "type" : "object" },
"then" : { "required" : ["name"] },
"dependencies" : {
"name" : {
"properties" : {
"name" : {"type" : "string"}
}
}
}
},
"juridical" : {
"if" : { "type" : "object" },
"then" : { "required" : ["tradeName"] },
"dependencies" : {
"tradeName" : {
"propertyNames" : {
"enum" : ["tradeName"]
},
"properties" : {
"tradeName" : {"type" : "string"}
}
}
}
}
},
"anyOf" : [
{"$ref" : "#/definitions/natural-is-null-juridical-is-an-object"},
{"$ref" : "#/definitions/natural-is-an-object-juridical-is-null"}
]
}
}
},
"definitions" : {
"natural-is-null-juridical-is-an-object" : {
"properties" : {
"natural" : { "type": "null"},
"juridical" : { "type" : "object"}
}
},
"natural-is-an-object-juridical-is-null" : {
"properties" : {
"natural" : { "type": "object"},
"juridical" : { "type" : "null"}
}
},
},
"examples" : [
{
"name": "Joao",
"partners": [
{
"juridical": null,
"natural": {

}
},
{
"juridical": {
"tradeName": "",
},
"natural": null
},
{
"juridical" : {},
"natural" : {}
},
{
"juridical" : null,
"natural" : null
}
]
},
]
}





share|improve this answer














Basically, JSON document either validates against JSON schema or not. This logic goes down through all sub-schemas and conditionals.



The content of error messages depends on specific implementation of JSON Schema validator. The one you use comes from a specific provider. As pointed by Relequestal, you cannot expect specific type of error message handling from specific implementation, unless it's what the provider documentation describes.



How about filing a suggestion to authors of the validator you use about extending messages for if-then-else case, feeding in your case?



Alternative approach: As I understand, your goal is to get as much specific error information as possible with this specific validator. It is what it is, so an alternative schema might fit the goal. As JSON Schema itself is a JSON document, thus you may consider a workaround by naming nodes in Schema in some consistent manner and using one of logical operators ("anyOf" (logical OR), "allOf" (logical AND), "oneOf" (logical XOR) ) instead of if-then-else.



Please note: schema based validator, in case of "allOf", "anyOf", "oneOf" is expected to run through all schemas until the logical condition is satisfied.




  • "allOf" - will check always if JSON doc validates against all schemas
    (AND)


  • "anyOf" - will check if JSON doc validates at least against 1 schema
    (OR, so some validator implementations might stop checking after
    first positive result as it's sufficient to evaluate check against
    "anyOf" to true),


  • "oneOf" - will check always if JSON doc validates exactly against
    one of enlisted schemas by checking against all of them (XOR)



(see: https://json-schema.org/draft-07/json-schema-validation.html#rfc.section.6.7.1 )



Thus if validated instance doesn't match schemas in above cases, the validator implementation may produce some 'false positives' in terms of error messages, as it will enlist issues encountered vs all schemas. It simply can't read our minds and guess what we meant by providing specific JSON doc, so it throws all on us to judge and decide.



One of many solutions could be to define variants of "juridical" and "natural" and combine them logically into schemas as in your case it seems you expect:




either juridical is an object (+relevant constraints) AND natural is not an object or juridical is not an object and natural is an object
(+relevant constraints).




Alternative schema (please note the "examples" section containing some test JSON documents):



{
"$schema": "http://json-schema.org/draft-07/schema#",
"type": "object",
"required": [
"name",
"partners"
],
"properties": {
"partners": {
"type": "array",
"items": {
"type": "object",
"anyOf" : [
{"$ref" : "#/definitions/juridical-is-object-and-natural-is-null"},
{"$ref" : "#/definitions/juridical-is-not-an-object-and-natural-is-an-object"}
],
"required" : ["natural","juridical"]
}
}
},
"examples" : [
{
"name": "Joao",
"partners": [
{
"juridical": null,
"natural": {

}
},
{
"juridical": {
"tradeName": ""
},
"natural": null
}
]
},
{
"name": "Joao",
"partners": [
{
"juridical": null,
"natural": {
"name" : ""
}
},
{
"juridical": {
"tradeName": ""
},
"natural": null
}
]
},
{
"name": "Joao",
"partners": [
{
"juridical": null,
"natural": {

}
},
{
"juridical": {
"tradeName": ""
},
"natural": null
},
{
"juridical" : ,
"natural" : {}
}
]
}
],
"definitions" : {
"natural" : {
"is-object" : {
"type" : "object",
"required": ["name"],
"properties": {
"name": {
"type": "string"
}
}
},
"is-not-an-object" : {
"not" : { "type" : "object" }
},
},
"juridical" : {
"is-object" : {
"type" : "object",
"required": ["tradeName"],
"properties": {
"name": {
"type": "string"
}
}
},
"is-not-an-object" : {
"not" : { "type" : "object" }
},
},
"juridical-is-object-and-natural-is-null" : {
"properties" : {
"natural" : {"$ref" : "#/definitions/natural/is-not-an-object"},
"juridical" : {"$ref" : "#/definitions/juridical/is-object"}
},
},
"juridical-is-not-an-object-and-natural-is-an-object" : {
"properties" : {
"natural" : {"$ref" : "#/definitions/natural/is-object"},
"juridical" : {"$ref" : "#/definitions/juridical/is-not-an-object"}
}
},
}
}


Notes:



"not" : { schema } error message might be confusing for casual users, but it conforms to the spec: https://json-schema.org/draft-07/json-schema-validation.html#rfc.section.6.7.4



Update



As explained in comments, you are after error details. Given the constraints of the selected tool in terms of if-then-else error details for more complex schemas, did you try to reshape schema using different keywords to trigger as less overhead messages as possible?



Alternative schema 2



{
"$schema": "http://json-schema.org/draft-07/schema#",
"type": "object",
"required": [
"name",
"partners"
],
"properties": {
"partners": {
"type": "array",
"items" : {
"properties" : {
"natural" : {
"if" : { "type" : "object" },
"then" : { "required" : ["name"] },
"dependencies" : {
"name" : {
"properties" : {
"name" : {"type" : "string"}
}
}
}
},
"juridical" : {
"if" : { "type" : "object" },
"then" : { "required" : ["tradeName"] },
"dependencies" : {
"tradeName" : {
"propertyNames" : {
"enum" : ["tradeName"]
},
"properties" : {
"tradeName" : {"type" : "string"}
}
}
}
}
},
"anyOf" : [
{"$ref" : "#/definitions/natural-is-null-juridical-is-an-object"},
{"$ref" : "#/definitions/natural-is-an-object-juridical-is-null"}
]
}
}
},
"definitions" : {
"natural-is-null-juridical-is-an-object" : {
"properties" : {
"natural" : { "type": "null"},
"juridical" : { "type" : "object"}
}
},
"natural-is-an-object-juridical-is-null" : {
"properties" : {
"natural" : { "type": "object"},
"juridical" : { "type" : "null"}
}
},
},
"examples" : [
{
"name": "Joao",
"partners": [
{
"juridical": null,
"natural": {

}
},
{
"juridical": {
"tradeName": "",
},
"natural": null
},
{
"juridical" : {},
"natural" : {}
},
{
"juridical" : null,
"natural" : null
}
]
},
]
}






share|improve this answer














share|improve this answer



share|improve this answer








edited Nov 19 at 21:04

























answered Nov 15 at 13:09









PsychoFish

81199




81199












  • Before knowing about the if statement in json schema, I was trying to use these logical operators (anyOf, oneOf, allOf). The problem was that if the statement doesn't match, it shows errors to all objects, natural and juridical, at the same time. So, if some, any or all of the schemas doesn't match, it applies all the schemas for each partner, and show me the errors.
    – João Pedro
    Nov 18 at 11:04










  • My goal is to know when a field was informed or not. I'd like to have a specific error that a field is required, so I can save it in database and expose an endpoint to request missing fields of an entity. I implemented a solution with JSON Path, but it doesn't seem the right tool to validate required fields, mainly when I have to apply a validation logic like with partners, that sometimes is natural or juridical (I know that It is a bad contract design). So I crated a rule model that exists a pre JSON Path validator field, that if true applies other rules related.
    – João Pedro
    Nov 18 at 11:12










  • Well, then it seems you should file a ticket to validator authors in regards to if-then-else detailed message. And yes, logical operators - that's what I meant, it throws all of them on you, as in case of invalid object there's no telepathic prediction what the object requestor meant. YOu may also consider usage of "dependencies" - but it may force you to change model. Did you try using "dependencies" like: when juridical field appears, it is an object - make something required?
    – PsychoFish
    Nov 18 at 13:50










  • Just to follow up: in order to use "dependencies" on object level and/or "contains" at array level (or even tupletyped validation), you'd need to have additional conditions defined in this case. Are there any? E.g. does the table must contain at least one object with juridical or natural being not null? One of each kind? Or maybe they need to be present in some specific sequence in the table?
    – PsychoFish
    Nov 19 at 9:17










  • @JoãoPedro I've updated answer with another alternative schema, shaped to trigger as much unique meaningful errors as possible, given the constraint of the tool for if-then-else errors details. However there is one 'anyOf' and meaningfulness of error details is dependent on well naming nodes in 'definitions' sections.
    – PsychoFish
    Nov 19 at 21:06


















  • Before knowing about the if statement in json schema, I was trying to use these logical operators (anyOf, oneOf, allOf). The problem was that if the statement doesn't match, it shows errors to all objects, natural and juridical, at the same time. So, if some, any or all of the schemas doesn't match, it applies all the schemas for each partner, and show me the errors.
    – João Pedro
    Nov 18 at 11:04










  • My goal is to know when a field was informed or not. I'd like to have a specific error that a field is required, so I can save it in database and expose an endpoint to request missing fields of an entity. I implemented a solution with JSON Path, but it doesn't seem the right tool to validate required fields, mainly when I have to apply a validation logic like with partners, that sometimes is natural or juridical (I know that It is a bad contract design). So I crated a rule model that exists a pre JSON Path validator field, that if true applies other rules related.
    – João Pedro
    Nov 18 at 11:12










  • Well, then it seems you should file a ticket to validator authors in regards to if-then-else detailed message. And yes, logical operators - that's what I meant, it throws all of them on you, as in case of invalid object there's no telepathic prediction what the object requestor meant. YOu may also consider usage of "dependencies" - but it may force you to change model. Did you try using "dependencies" like: when juridical field appears, it is an object - make something required?
    – PsychoFish
    Nov 18 at 13:50










  • Just to follow up: in order to use "dependencies" on object level and/or "contains" at array level (or even tupletyped validation), you'd need to have additional conditions defined in this case. Are there any? E.g. does the table must contain at least one object with juridical or natural being not null? One of each kind? Or maybe they need to be present in some specific sequence in the table?
    – PsychoFish
    Nov 19 at 9:17










  • @JoãoPedro I've updated answer with another alternative schema, shaped to trigger as much unique meaningful errors as possible, given the constraint of the tool for if-then-else errors details. However there is one 'anyOf' and meaningfulness of error details is dependent on well naming nodes in 'definitions' sections.
    – PsychoFish
    Nov 19 at 21:06
















Before knowing about the if statement in json schema, I was trying to use these logical operators (anyOf, oneOf, allOf). The problem was that if the statement doesn't match, it shows errors to all objects, natural and juridical, at the same time. So, if some, any or all of the schemas doesn't match, it applies all the schemas for each partner, and show me the errors.
– João Pedro
Nov 18 at 11:04




Before knowing about the if statement in json schema, I was trying to use these logical operators (anyOf, oneOf, allOf). The problem was that if the statement doesn't match, it shows errors to all objects, natural and juridical, at the same time. So, if some, any or all of the schemas doesn't match, it applies all the schemas for each partner, and show me the errors.
– João Pedro
Nov 18 at 11:04












My goal is to know when a field was informed or not. I'd like to have a specific error that a field is required, so I can save it in database and expose an endpoint to request missing fields of an entity. I implemented a solution with JSON Path, but it doesn't seem the right tool to validate required fields, mainly when I have to apply a validation logic like with partners, that sometimes is natural or juridical (I know that It is a bad contract design). So I crated a rule model that exists a pre JSON Path validator field, that if true applies other rules related.
– João Pedro
Nov 18 at 11:12




My goal is to know when a field was informed or not. I'd like to have a specific error that a field is required, so I can save it in database and expose an endpoint to request missing fields of an entity. I implemented a solution with JSON Path, but it doesn't seem the right tool to validate required fields, mainly when I have to apply a validation logic like with partners, that sometimes is natural or juridical (I know that It is a bad contract design). So I crated a rule model that exists a pre JSON Path validator field, that if true applies other rules related.
– João Pedro
Nov 18 at 11:12












Well, then it seems you should file a ticket to validator authors in regards to if-then-else detailed message. And yes, logical operators - that's what I meant, it throws all of them on you, as in case of invalid object there's no telepathic prediction what the object requestor meant. YOu may also consider usage of "dependencies" - but it may force you to change model. Did you try using "dependencies" like: when juridical field appears, it is an object - make something required?
– PsychoFish
Nov 18 at 13:50




Well, then it seems you should file a ticket to validator authors in regards to if-then-else detailed message. And yes, logical operators - that's what I meant, it throws all of them on you, as in case of invalid object there's no telepathic prediction what the object requestor meant. YOu may also consider usage of "dependencies" - but it may force you to change model. Did you try using "dependencies" like: when juridical field appears, it is an object - make something required?
– PsychoFish
Nov 18 at 13:50












Just to follow up: in order to use "dependencies" on object level and/or "contains" at array level (or even tupletyped validation), you'd need to have additional conditions defined in this case. Are there any? E.g. does the table must contain at least one object with juridical or natural being not null? One of each kind? Or maybe they need to be present in some specific sequence in the table?
– PsychoFish
Nov 19 at 9:17




Just to follow up: in order to use "dependencies" on object level and/or "contains" at array level (or even tupletyped validation), you'd need to have additional conditions defined in this case. Are there any? E.g. does the table must contain at least one object with juridical or natural being not null? One of each kind? Or maybe they need to be present in some specific sequence in the table?
– PsychoFish
Nov 19 at 9:17












@JoãoPedro I've updated answer with another alternative schema, shaped to trigger as much unique meaningful errors as possible, given the constraint of the tool for if-then-else errors details. However there is one 'anyOf' and meaningfulness of error details is dependent on well naming nodes in 'definitions' sections.
– PsychoFish
Nov 19 at 21:06




@JoãoPedro I've updated answer with another alternative schema, shaped to trigger as much unique meaningful errors as possible, given the constraint of the tool for if-then-else errors details. However there is one 'anyOf' and meaningfulness of error details is dependent on well naming nodes in 'definitions' sections.
– PsychoFish
Nov 19 at 21:06


















draft saved

draft discarded




















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.





Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


Please pay close attention to the following guidance:


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53225270%2fschema-draft-v7-if-statement-is-not-informing-error-in-detail%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Wiesbaden

Marschland

Dieringhausen