описание свойства схемы json и использование $ ref

Я пишу схему json для проверки моих выходных данных json, созданных exe. Схема немного сложна, я определил некоторые "определения", на которые есть ссылки в свойствах ("$ ref": "# / definitions / ...) Использование определений здесь тем более важно, потому что у меня есть случай, когда определение рекурсивно.

Моя схема теперь работает хорошо, она правильно проверяет мои выходные данные json.

Теперь я пытаюсь правильно задокументировать схему, используя ключевое слово description для каждого свойства. Для разработки схемы я использую редактор (XMLSpy), который представляет схему графически. Это очень полезно, но я сталкиваюсь с любопытным поведением, и я не знаю, проблема ли это в редакторе или это я не совсем понимаю.

Вот минимальный пример схемы json, объясняющий мою проблему:

{
	"$schema": "http://json-schema.org/draft-04/schema#",
	"type": "object",
	"properties": {
		"sourcePath": {
			"$ref": "#/definitions/Path",
			"description": "Here the description where I expected to set it"
		},
		"targetPath": {
			"$ref": "#/definitions/Path",
			"description": "Here another description where I expected to set it to that property of the same kind but whith a different use."
		}
	},
	"additionalProperties": false,
	"definitions": {
		"Path": {
			"description": "Here the descriptiond where it is set by the software",
			"type": "object",
			"properties": {
				"aUsefulProperty": {
					"type": "string"
				},
				"parentPath": {
					"$ref": "#/definitions/Path",
					"description": "Here yest another description where I expected to set it.."
				}
			},
			"required": [
				"aUsefulProperty"
			],
			"additionalProperties": false
		}
	}
}

Когда я пытаюсь добавить описание к свойству, редактор фактически добавляет описание внутри определения объекта. Как следствие, редактор отображает это описание для обоих свойств «sourcePath» и «targetPath», более того, он отображает это описание также в «parentPath».

Мое намерение состоит в том, чтобы иметь три разных описания, по одному для каждого свойства (и, возможно, также само определение, но это не проблема). Если я добавлю их в схему json вручную, проблем не возникнет, но эти описания не появятся в графическом редакторе.

Итак, я запутался.

Как вы думаете, проблема в моем графическом редакторе, или я ошибаюсь?

В принципе, когда мы используем «$ ref» для определения свойства, можно ли добавить какое-либо другое поле в качестве описания или использование «$ ref» подразумевает, что больше ничего не используется? В таком случае, как я могу правильно задокументировать собственность?

Я должен предоставить свои схемы json некоторым партнерам, которые должны будут использовать их в качестве документации для получения правильного вывода json. Поэтому, насколько это возможно, я хотел бы предоставить им самодокументирующуюся схему json, как мы можем сделать с XML.

Спасибо


person Azias    schedule 06.11.2015    source источник


Ответы (2)


Любые члены, кроме "$ ref" в ссылочном объекте JSON, ДОЛЖНЫ игнорироваться.

Чтобы установить description, вам нужно будет сделать что-то вроде следующего примера. Это может вызвать другие странности в вашем редакторе, но я уверен, что это самый чистый способ сделать это.

Оригинал:

{
    "$ref": "#/definitions/Path",
    "description": "Here the description where I expected to set it"
}

Предлагаемое исправление:

{
    "allOf": [{ "$ref": "#/definitions/Path" }],
    "description": "Here the description where I expected to set it"
}
person Jason Desrosiers    schedule 12.11.2015
comment
Спасибо за этот ответ. Проблема, которую я вижу, заключается в том, что когда я использую такой оператор, как allOf или oneOf, объект, использующий этот оператор, должен повторять все свойства комбинированных схем (или иметь возможность разрешить любое свойство, поэтому мы не можем добавить additionalProperties: false). Это проблема в текущем формате json, возможно, это будет исправлено в будущей версии. В любом случае, просто добавить комментарий немного сложно. Но теперь у меня есть ответ, который я искал: при использовании $ ref любые члены, кроме $ ref в объекте ссылки JSON, ДОЛЖНЫ игнорироваться. Спасибо. - person Azias; 15.11.2015
comment
Я знаю проблему, о которой вы говорите, но в этом простом случае у вас не должно возникнуть никаких проблем. Проблема, которую вы описываете, заключается в том, почему при работе со схемой JSON рекомендуется игнорировать дополнительные свойства, а не запрещать их явно. - person Jason Desrosiers; 16.11.2015
comment
Я согласен в целом, но здесь json будет анализироваться приемником, который может аварийно завершить работу при возникновении неожиданного свойства, поэтому ... (я знаю, что решение состоит в том, чтобы исправить синтаксический анализатор). Я уже использую некоторые операторы как allOf и anyOf в своей схеме, но это кажется слишком сложным для добавления комментария. На самом деле решение, которое мы, вероятно, выберем в конечном итоге, - это сгенерировать схему json из модели UML (которая у нас уже есть), поэтому документация и комментарии, наконец, будут в UML. - person Azias; 18.11.2015
comment
Я согласен с тем, что дополнительная сложность, вероятно, не стоит того, чтобы использовать только метаданные, если вы не используете ее для создания чего-то вроде своей документации. Если бы это были просто заметки для команды разработчиков, она бы просто оставила их рядом с $ref и позволила бы любым инструментам игнорировать их. Удачи вам с подходом UML. Я вообще не фанат создания кода, но надеюсь, что у вас это сработает. Если вам нравится работать с UML, имеет смысл поместить его в центр вашего приложения вот так. - person Jason Desrosiers; 18.11.2015
comment
Это не совсем правильно, потому что allOf - это массив. Это должно быть "allOf": [ { "$ref": "#/definitions/Path" } ], - person Millie Smith; 23.05.2019
comment
Ой! Спасибо, что поймал @MillieSmith. Отредактирую ответ. - person Jason Desrosiers; 23.05.2019

В текущем проекте схемы JSON допускается переопределение ключевых слов из $refs. Схема в исходном вопросе будет считаться действительной (в зависимости от черновика ...)

Из исходного сообщения

    ...
    "properties": {
        "sourcePath": {
            "$ref": "#/definitions/Path",
            "description": "Here the description where I expected to set it"
        },
        "targetPath": {
            "$ref": "#/definitions/Path",
            "description": "Here another description where I expected to set it to that property of the same kind but whith a different use."
        }
    },
   ...

Спецификация схемы JSON включает идентичный пример:

Из проекта схемы JSON2019

            ....
            "properties": {
                "enabled": {
                    "description": "If set to null, Feature B
                                    inherits the enabled
                                    value from Feature A",
                    "$ref": "#/$defs/enabledToggle"
                }
            }
            ...

Сценарий использования в вопросе был именно тем, что описывает спецификация схемы JSON. Фактически, вы можете переопределить любое из ключевых слов аннотации (например, title, description, default, examples). В приведенном выше примере также показано переопределение свойства "по умолчанию".

К сожалению, стандарт делает это необязательным.

Приложения МОГУТ принимать решения о том, какое из нескольких значений аннотации использовать, в зависимости от местоположения схемы, которое внесло значение. Это сделано для обеспечения гибкости использования.

Поэтому вам следует проверить это, прежде чем полагаться на это.

person Carlo Quinonez    schedule 12.11.2019
comment
Новый $ref логически эквивалентен старому $ref, заключенному в allOf. В случае, если это не ясно, родственные ключевые слова $ref не ограничиваются ключевыми словами аннотации, и до сих пор нет концепции переопределения чего-либо. У свойства будет два описания, а не одно, перекрывающее другое. Однако только для ключевых слов аннотаций реализация МОЖЕТ использовать эти аннотации, как они сочтут нужным. Это создает достаточно свободную спецификацию, чтобы реализации могли принимать переопределяющий тип поведения для аннотаций без нарушения спецификации. - person Jason Desrosiers; 12.11.2019