Я нахожу схему json для проверки моих json-выходов, созданных exe. Схема, которая немного сложна, я определил некоторые «определения», на которые ссылаются свойства (" $ ref ":" #/определения/...). И использование определений здесь тем более важно, потому что у меня есть случай, когда определение является рекурсивным.
Моя схема теперь работает хорошо, она корректно проверяет мои json-выходы .
Теперь я пытаюсь правильно документировать схему, используя ключевое слово "description" для каждого свойства. Для разработки схемы я использую редактор (XMLSpy), который представляет схему графически. Это очень полезно, но мне кажется, behaviou r, и я не знаю, является ли это проблемой в редакторе, или я не понимаю этого.
Вот минимальный пример JSon схемы, чтобы объяснить мою проблему:
{
\t "$schema": "http://json-schema.org/draft-04/schema#",
\t "type": "object",
\t "properties": {
\t \t "sourcePath": {
\t \t \t "$ref": "#/definitions/Path",
\t \t \t "description": "Here the description where I expected to set it"
\t \t },
\t \t "targetPath": {
\t \t \t "$ref": "#/definitions/Path",
\t \t \t "description": "Here another description where I expected to set it to that property of the same kind but whith a different use."
\t \t }
\t },
\t "additionalProperties": false,
\t "definitions": {
\t \t "Path": {
\t \t \t "description": "Here the descriptiond where it is set by the software",
\t \t \t "type": "object",
\t \t \t "properties": {
\t \t \t \t "aUsefulProperty": {
\t \t \t \t \t "type": "string"
\t \t \t \t },
\t \t \t \t "parentPath": {
\t \t \t \t \t "$ref": "#/definitions/Path",
\t \t \t \t \t "description": "Here yest another description where I expected to set it.."
\t \t \t \t }
\t \t \t },
\t \t \t "required": [
\t \t \t \t "aUsefulProperty"
\t \t \t ],
\t \t \t "additionalProperties": false
\t \t }
\t }
}
Когда я пытаюсь добавить описание свойства, редактор фактически добавить описание внутри определение объекта. В результате редактор отображает это описание как для свойств «sourcePath», так и для «targetPath», кроме того, оно отображает это описание также в «parentPath».
Мое намерение состоит в том, чтобы иметь три разных описания по одному для каждого свойства (и, возможно, также само определение, но это не проблема). Если я добавлю их вручную в json-схему, нет проблем, но эти описания не отображаются в графическом редакторе.
Итак, я смущен.
Считаете ли вы, что это проблема с моим графическим редактором или я ошибаюсь?
В принципе, когда мы используем «$ ref» для определения свойства, можно ли добавить другое поле в качестве описания, или же использование «$ ref» подразумевает не использование ничего другого? В этом случае, как я могу правильно документировать свойство?
Я должен предоставить свои json-схемы некоторым партнерам, которые должны будут использовать их в качестве документации для создания правильного выхода json. Поэтому, насколько это возможно, я хотел бы предоставить им самодокументирующую json-схему, как мы можем это сделать с XML.
Благодаря
Спасибо за этот ответ. Проблема, которую я вижу, заключается в том, что я использую оператор, такой как «allOf» или «oneOf», что объект, который использует этот оператор, должен повторять все свойства комбинированных схем (или иметь возможность разрешить любое свойство, поэтому мы не можем добавить «дополнительные свойства» ": ложный). Это проблема в текущем json формате, возможно, это будет исправлено в версии futur. В любом случае, это просто сложно добавить комментарий. Но теперь у меня есть ответ, который я искал: при использовании «$ ref» любые члены, кроме «$ ref» в объекте Reference JSON, будут проигнорированы. Спасибо. – Azias
Я знаю проблему, о которой вы говорите, но вы не должны сталкиваться с какими-либо проблемами в этом простом случае. Проблема, которую вы описываете, - это то, почему при работе с JSON Schema лучше всего игнорировать дополнительные свойства, а не явно запрещать их. – Jason
Я согласен в целом, но здесь json будет разбираться с приемником, который может произойти сбой при неожиданном свойстве, поэтому ... (Я знаю, что решение должно исправить парсер). Я уже использую некоторый оператор как «allOf» и «anyOf» в моей схеме, но кажется, что это слишком сложно, чтобы добавить комментарий. На самом деле решение, которое мы, вероятно, и, наконец, выберем, это генерировать json-схему из UML-модели (которая у нас уже есть), поэтому документация и комментарии, наконец, будут в UML. – Azias