JSON схема - валидна, ако обектът *не* съдържа определено свойство

Възможно ли е да се настрои JSON схема, която все още позволява additionalProperties, но не съвпада, ако присъства много конкретно име на свойство? С други думи, трябва да знам дали е възможно да имам точно обратното на required декларацията.

Схема:

{
    "type": "object",
    "properties": {
        "x": { "type": "integer" }
    },
    "required": [ "x" ],
    "ban": [ "z" ] // possible?
}

Съвпада:

{ "x": 123 }

Съвпада:

{ "x": 123, "y": 456 }

Не съвпадение:

{ "x": 123, "y": 456, "z": 789 }

json jsonschema
person M Miller    schedule 28.05.2015    source източник

Отговори (5)


arrow_upward
35
arrow_downward

Това, което искате да направите, може да бъде постигнато с помощта на ключовата дума not. Ако схемата not се валидира, родителската схема няма да се валидира.

{
    "type": "object",
    "properties": {
        "x": { "type": "integer" }
    },
    "required": [ "x" ],
    "not": { "required": [ "z" ] }
}
person Jason Desrosiers    schedule 05.06.2015
comment
Не е задължително не означава, че не трябва да присъства. - person jruizaranguren; 09.06.2015
comment
@jruizaranguren, опитваш се да кажеш, че този отговор е грешен? Мога да разширя обяснението си, ако не е ясно защо тази схема отговаря на въпроса. - person Jason Desrosiers; 10.06.2015
comment
Ти си прав. Не съм прав. Няма нужда от разширяване на обяснението. - person jruizaranguren; 10.06.2015
comment
Въпреки че е правилен в JSON схемата, споделям объркването на @jruizaranguren относно логиката. (Не е единственото място в JSON схемата, за съжаление. :/) - person Raphael; 05.07.2018
comment
Също така мисля, че е синтактично объркващо (въпреки че работи, за да избегне присъствието на параметъра). От друга страна, валидаторите, които съм използвал, не предоставят ясна грешка в такива ситуации. - person adripanico; 04.10.2019
comment
@adripanico - от първоначалното запитване нямаше да работи, но с Draft 6+ комбинация от not: {propertyNames: {enum: [bad, properties]}} работи добре с Валидатори, предоставяйки конкретни невалидни имена на свойства при върнати грешки . - person RealBlueSky; 14.02.2020
comment
@JasonDesrosiers Това, което jruizaranguren се опитва да намекне е, че not required означава even if it is there it doesn't matter. Това не е проблем с вашия отговор, а със смисъла на синтаксиса на JSON схемата. "not": { "required": [ "z" ] } не означава същото на естествен английски.. - person Romeo Sierra; 28.02.2020
comment
Здравейте, опитвам се да постигна нещо подобно на това, което OP поиска. Искам да забраня друго свойство освен z. Ако го добавя към незадължителния масив: not: {required: [z,y]} и в тялото на json изпратих само свойствата x и z, той проверява: Това ли е очакваното поведение? - person jrf; 06.04.2020
comment
@jrf Смешно е, че питаш това, защото току-що отговорих на този въпрос преди няколко часа и това не е често срещан въпрос. Разделът Какво става с required-not трябва да отговори на въпроса ви stackoverflow.com/a/61062869/1320693 - person Jason Desrosiers; 06.04.2020
comment
Уау, благодаря @JasonDesrosiers! Търся тези теми в SO от доста дни, но не намерих много. Тези въпроси са точно това, което се опитвам да направя... Мислех, че разтягам възможностите на json-schema твърде много, но предполагам, че не съм единственият! Благодаря! - person jrf; 06.04.2020

arrow_upward
32
arrow_downward

Има по-прост подход. Дефинирайте, че ако x присъства, той не трябва да отговаря на никаква схема. Чрез привеждане до абсурд x не може да присъства:

{
    "properties" : {
        "x" : {
            "not" : {}

        }
    }
}

Актуализация 2020/04/16: Както е посочено от @Carsten в коментар, от чернова версия 05 и по-нова, предложената схема може да бъде опростена, както следва:

{
    "properties": {
       "x": false
    }
}
person jruizaranguren    schedule 09.06.2015
comment
Най-удобният и необъркващ отговор за мен. Особеното предимство на него е, че се поставя в ключова дума properties, заедно с други свойства. - person 1valdis; 29.12.2018
comment
IMO не е отговор на този конкретен въпрос, но е наистина добър. - person kris_IV; 05.12.2019
comment
Кратко описание на ”x”: { ”not”: {} } в по-новите чернови ще бъде ”x”: false. - person Carsten; 15.04.2020

arrow_upward
5
arrow_downward

Реших проблема, като забраних допълнителни свойства чрез "additionalProperties": false, но използвах patternProperties, за да разреша всяко име на свойство освен забраненото.

{
    "type": "object",
    "properties": {
        "x": { "type": "integer" }
    },
    "required": [ "x" ],
    "patternProperties": {
        "^(?!^z$).*": {}
    },
    "additionalProperties": false
}
person M Miller    schedule 28.05.2015

arrow_upward
4
arrow_downward

За да посочите липсата на поле, можете да очаквате неговият тип да бъде null.

{
    "type": "object",
    "properties": {
        "x": { "type": "integer" },
        "z": { "type": "null" }

    },
    "required": [ "x" ]
}
person Tomás Senart    schedule 25.01.2019
comment
Дали „null“ е същото като „undefined“? - person jamesjansson; 06.11.2019

arrow_upward
-1
arrow_downward

Можете да имате тип null за това конкретно свойство:

 z : {
"type": "null"
}
person swarnim gupta    schedule 17.08.2020